Done.
Ok, here is the modified encoding table (column1 is the standard name,
2 is our official name, and 3 is alias). If there's no objection, I
will change them.
ASCII SQL_ASCII
UTF-8 UNICODE UTF_8
MULE-INTERNAL MULE_INTERNAL
ISO-8859-1LATIN1
* Tatsuo Ishii [EMAIL PROTECTED] [011014 16:05]:
ASCII SQL_ASCII
UTF-8 UNICODE UTF_8
MULE-INTERNAL MULE_INTERNAL
ISO-8859-1 LATIN1 ISO_8859_1
ISO-8859-2 LATIN2 ISO_8859_2
ASCII SQL_ASCII
UTF-8 UNICODE UTF_8
MULE-INTERNAL MULE_INTERNAL
ISO-8859-1 LATIN1 ISO_8859_1
ISO-8859-2 LATIN2 ISO_8859_2
ISO-8859-3 LATIN3
Tatsuo,
Did you ever commit this new function? I just tried a 'select
pg_client_encoding()' and it told me that there was no such function.
This was on sources that I pulled and built two days ago.
I was planning on changing the JDBC code to use this function instead of
On Mon, Sep 10, 2001 at 01:46:28PM +0900, Tatsuo Ishii wrote:
Hi,
I'm going to add a new function pg_client_encoding returning the
current client side encoding name. I know there is a similar
functionality already there in PostgreSQL (show client_encoding) but
it's pain to handle notice
Hi,
I'm going to add a new function pg_client_encoding returning the
current client side encoding name. I know there is a similar
functionality already there in PostgreSQL (show client_encoding) but
it's pain to handle notice message by a program.
Also note that JDBC driver and maybe some other
