From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Dario V(dot) Fassi" <software(at)sistemat(dot)com(dot)ar>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Very strange Error in Updates |
Date: | 2004-07-16 00:17:54 |
Message-ID: | 40F71EB2.9080304@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>
>>What about refusing to change client_encoding to something other than
>>SQL_ASCII on SQL_ASCII databases?
>
>
> Not sure that would do anything very useful. People who aren't thinking
> about this probably aren't thinking about setting client_encoding
> properly, either.
I was thinking about it from the other angle -- clients that set
client_encoding and expect the server to do the conversion (e.g. the
JDBC driver) will see an error rather than bogus unconverted data.
What does the server currently do if you ask for a client_encoding that
isn't supported by the database encoding (e.g. LATIN1<->LATIN2)? It
seems to me that SQL_ASCII is kinda-sorta-if-you-squint-a-bit like an
encoding that doesn't support any client_encoding but SQL_ASCII.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-16 03:11:49 | Re: [HACKERS] Weird new time zone |
Previous Message | Simon Riggs | 2004-07-16 00:02:38 | Re: Point in Time Recovery |
From | Date | Subject | |
---|---|---|---|
Next Message | Dario V. Fassi | 2004-07-16 03:13:01 | Re: Very strange Error in Updates - Worst than ever ! |
Previous Message | Tom Lane | 2004-07-15 23:59:20 | Re: Very strange Error in Updates |