From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] invalid byte sequence ? |
Date: | 2006-08-25 18:53:59 |
Message-ID: | 20060825185359.GN14622@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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
> locale.
This sounds like a good idea anyway...
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Munro | 2006-08-25 18:55:49 | Something blocking in libpq_gettext? |
Previous Message | Matteo Bertini | 2006-08-25 18:48:43 | Re: hint unique result fro union |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-08-25 23:46:57 | New XML section for documentation |
Previous Message | Tom Lane | 2006-08-25 18:43:34 | Re: [GENERAL] invalid byte sequence ? |