Re: Very strange Error in Updates

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