Thread: ascii to character conversion in postgres
Postgres has an 'ascii' function that converts characters to ascii, values, but it appears to be a one way street. I can't find a way to convert ascii values to characters, like 'chr' in Oracle. Anyone know how to do this? -Alex __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
On Sat, 16 Sep 2000, Alex Sokoloff wrote:
> Postgres has an 'ascii' function that converts
> characters to ascii, values, but it appears to be a
> one way street. I can't find a way to convert ascii
> values to characters, like 'chr' in Oracle. Anyone
> know how to do this?
Interesting for me, I try explore (or write) it next week :-)
By the way, the Oracle has more interesting fuction that can
season DB's users life and I mean that for porting from rich
Oracle to great PostgreSQL we need it....
Karel
>> Postgres has an 'ascii' function that converts
>> characters to ascii, values, but it appears to be a
>> one way street. I can't find a way to convert ascii
>> values to characters, like 'chr' in Oracle. Anyone
>> know how to do this?
ichar(). Since that's part of the "oracle_compatibility" file,
I'd assumed the function name spelling was the same as Oracle's.
Not so?
regards, tom lane
On Sun, 17 Sep 2000, Tom Lane wrote:
> >> Postgres has an 'ascii' function that converts
> >> characters to ascii, values, but it appears to be a
> >> one way street. I can't find a way to convert ascii
> >> values to characters, like 'chr' in Oracle. Anyone
> >> know how to do this?
>
> ichar(). Since that's part of the "oracle_compatibility" file,
> I'd assumed the function name spelling was the same as Oracle's.
> Not so?
Not documented (from oracle_compat.c) in PG documentation:
btrim()ascii()ichar()repeat()
and about ichar() is nothing in Oracle documentation, it's knows chr()
only...
Directly rename it, or add "alias" entry to the pg_proc?
Or ignore? :-)
Karel
Karel Zak <zakkr@zf.jcu.cz> writes:
> Not documented (from oracle_compat.c) in PG documentation:
> btrim()
> ascii()
> ichar()
> repeat()
> and about ichar() is nothing in Oracle documentation, it's knows chr()
> only...
Sounds to me like calling it ichar() was an error, then. Should be chr().
> Directly rename it, or add "alias" entry to the pg_proc?
The alias would only be useful to people who had been using it as
"ichar()" --- which is not many people, since it's undocumented ;-)
Furthermore, now that I look, it looks like ichar() was new in
contrib/odbc in 7.0 and has only recently been moved into the main
code.
I vote for just renaming it to chr(). Any objections?
regards, tom lane
On Mon, 18 Sep 2000, Tom Lane wrote:
> Karel Zak <zakkr@zf.jcu.cz> writes:
> > Not documented (from oracle_compat.c) in PG documentation:
> > btrim()
> > ascii()
> > ichar()
> > repeat()
> > and about ichar() is nothing in Oracle documentation, it's knows chr()
> > only...
>
> Sounds to me like calling it ichar() was an error, then. Should be chr().
>
> > Directly rename it, or add "alias" entry to the pg_proc?
>
> The alias would only be useful to people who had been using it as
> "ichar()" --- which is not many people, since it's undocumented ;-)
> Furthermore, now that I look, it looks like ichar() was new in
> contrib/odbc in 7.0 and has only recently been moved into the main
> code.
>
> I vote for just renaming it to chr(). Any objections?
first thing off the top of my head ... was there a reason why it was added
to contrib/odbc? ignoring the "oracle documentation", is it something
that is/was needed for ODBC?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
>> I vote for just renaming it to chr(). Any objections?
> first thing off the top of my head ... was there a reason why it was added
> to contrib/odbc? ignoring the "oracle documentation", is it something
> that is/was needed for ODBC?
Now that I look, it seems ODBC specifies the function as "char()",
which means contrib/odbc is wrong on that score too :-(
New proposal: forget ichar(), give the function two entries chr() and
char().
regards, tom lane
On Mon, 18 Sep 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > >> I vote for just renaming it to chr(). Any objections? > > > first thing off the top of my head ... was there a reason why it was added > > to contrib/odbc? ignoring the "oracle documentation", is it something > > that is/was needed for ODBC? > > Now that I look, it seems ODBC specifies the function as "char()", > which means contrib/odbc is wrong on that score too :-( > > New proposal: forget ichar(), give the function two entries chr() and > char(). sounds good to me ... chr() == char(), I take it? is there a reason for having both vs just changing char() to chr() in the odbc stuff?
The Hermit Hacker <scrappy@hub.org> writes:
> sounds good to me ... chr() == char(), I take it? is there a reason for
> having both vs just changing char() to chr() in the odbc stuff?
We don't control the ODBC specification ...
regards, tom lane
On Mon, 18 Sep 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > sounds good to me ... chr() == char(), I take it? is there a reason for > > having both vs just changing char() to chr() in the odbc stuff? > > We don't control the ODBC specification ... okay, granted, but, other then ODBC, do we need the char() type? could it not be an internal translation in the ODBC driver itself?
Tom Lane writes: > ichar(). Since that's part of the "oracle_compatibility" file, > I'd assumed the function name spelling was the same as Oracle's. > Not so? ichar() is for ODBC compliance. chr() could probably be an alias to it. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
I wrote: > ichar() is for ODBC compliance. chr() could probably be an alias to it. Ignore that. Probably "char()" had some parsing or overloading problems. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Of course, if an alias for ichar is carried forward I can write code for the current postgres that won't break with future releases. I realize that I might end up being the only person on the planet who ends up using ichar, and that may not be sufficient justification for an alias.... Best, Alex --- Tom Lane <tgl@sss.pgh.pa.us> wrote: > > New proposal: forget ichar(), give the function two > entries chr() and > char(). > > regards, tom lane __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
> New proposal: forget ichar(), give the function two entries chr() and
> char().
OK, I will send patch for this and send domumentation for all
oracle_compat.c routines...
I don't want make some changes to contrib/odbc, because it's out of
me... but I have a question, Why in the contrib/odbc/odbc.c are total
same function as in oracle_compat.c (like ascii(), ichar(), repeat())?
Is it anything specific for ODBC?
Karel
Alex Sokoloff <alex_sokoloff@yahoo.com> writes:
> Of course, if an alias for ichar is carried forward I
> can write code for the current postgres that won't
> break with future releases. I realize that I might end
> up being the only person on the planet who ends up
> using ichar, and that may not be sufficient
> justification for an alias....
Well, we will certainly have chr(), so why not save yourself the
trouble of converting later and make that alias today?
create function chr(int4) returns text as 'ichar'
language 'internal' with (iscachable);
ought to do it in 7.0.*.
regards, tom lane
Karel Zak <zakkr@zf.jcu.cz> writes:
> I don't want make some changes to contrib/odbc, because it's out of
> me... but I have a question, Why in the contrib/odbc/odbc.c are total
> same function as in oracle_compat.c (like ascii(), ichar(), repeat())?
contrib/odbc was a quick hack just before 7.0 release; we had already
frozen the system catalogs for 7.0, and didn't want to force another
initdb for beta testers. It's not supposed to survive into 7.1 --- most
or all of what's in there should be, or perhaps already has been, merged
into the main code.
Thomas did the work on that originally, and might remember more about
whether any of the ODBC compatibility functions ought *not* go into
the main tree.
regards, tom lane
Karel Zak writes: > I don't want make some changes to contrib/odbc, because it's out of > me... but I have a question, Why in the contrib/odbc/odbc.c are total > same function as in oracle_compat.c (like ascii(), ichar(), repeat())? The odbc.c file is for installing the set of ODBC compatibility functions into a pre-7.0 server. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/