On Wed, Aug 23, 2006 at 06:52:00PM -0400, Tom Lane wrote: > A possible solution therefore is to have psql or libpq drive the > client_encoding off the client's locale environment instead of letting > it default to equal the server_encoding. But I'm not sure what > downsides that would have, and in any case it's not entirely clear that > we can always derive the correct Postgres encoding name from the > system's locale info.
For glibc systems we can get 100% reliable results. Even for other systems there's standard code out there for determining the charset. But this has been discussed before: http://archives.postgresql.org/pgsql-hackers/2003-05/msg00744.php http://archives.postgresql.org/pgsql-general/2004-04/msg00470.php http://archives.postgresql.org/pgsql-hackers/2006-06/msg01027.php It seems to me that setting the client encoding based on the client-locale is the *only* sensible way of doing it. The locale is going to effect the results of programs like sort and any scripts used to process the data anyway. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
