ascii to character conversion in postgres

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/