Oliver Jowett <oliver@opencloud.com> writes:
> Tom Lane wrote:
>> Not really. SQL_ASCII encoding basically means "we don't know what this
>> data is, just store it verbatim". So the UTF-8 string sent by the
>> driver is stored verbatim.
> Hmm, so SQL_ASCII is not really a first-class encoding -- it doesn't do
> encoding conversions at all?
Correct. BTW, setting client_encoding to SQL_ASCII also disables
on-the-wire encoding conversions (so that client data had better be in
whatever the database encoding is).
> 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.
> Or perhaps the JDBC driver could issue a warning whenever it notices the
> underlying encoding is SQL_ASCII (this means another round-trip on
> connection setup even when using V3 though).
Something like this seems reasonable. I'm not sure why we didn't make
server_encoding be GUC_REPORT so that it would be sent automatically
during connection startup ... we could change that in 7.5 if it would
help any ...
> Sure -- it just depends on what other clients use the db. By the sounds
> of it in this case the other client is an ODBC client that isn't aware
> of encodings at all.. I suppose this can be handled by the default
> client_encoding setting in postgresql.conf?
Yeah, as long as there is one specific encoding that all the
encoding-ignorant clients are using. If there's more than one, perhaps
you could get it to work by specifying per-user or per-database default
client_encoding settings (see ALTER USER and ALTER DATABASE).
regards, tom lane
