Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > And as a counter-example: pg_dump should absolutly not use the client
> > locale, it should always dump as the same encoding as the server...
> Sure, but pg_dump should set that explicitly. I'm prepared to believe
> that looking at the locale is sane for all normal clients.
What are "normal clients"? I would think that programs in PHP or Perl
have their own idea of the correct encoding (JDBC already has one).
> It might be worth providing a way to set the client_encoding through a
> PQconnectdb connection-string keyword, just in case the override-via-
> PGCLIENTENCODING dodge doesn't suit someone. The priority order
> would presumably be connection string, then PGCLIENTENCODING, then
This sounds like a good idea anyway...
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2006-08-25 23:46:57|
|Subject: New XML section for documentation|
|Previous:||From: Tom Lane||Date: 2006-08-25 18:43:34|
|Subject: Re: [GENERAL] invalid byte sequence ? |
pgsql-general by date
|Next:||From: Marc Munro||Date: 2006-08-25 18:55:49|
|Subject: Something blocking in libpq_gettext?|
|Previous:||From: Matteo Bertini||Date: 2006-08-25 18:48:43|
|Subject: Re: hint unique result fro union|