From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <bruce(at)momjian(dot)us>, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
Subject: | Re: encoding of PostgreSQL messages |
Date: | 2009-02-12 06:10:07 |
Message-ID: | 200902120810.09272.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wednesday 11 February 2009 18:00:31 Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Tom Lane wrote:
> >> Reflecting on the bigger picture ... I would imagine that the vast
> >> majority of existing applications depend on client_encoding settings
> >> that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
> >> just the default (== database encoding). I don't think a solution that
> >> penalizes those cases and makes only the case of setting it via
> >> PGCLIENTENCODING work nicely is going to make very many people happy.
> >
> > I don't have any survey data available, but I think this assessment is
> > semantically wrong. Usefully, the client encoding can come only from
> > the client, or be defaulted (and even that is semantically wrong).
>
> In an ideal world, perhaps so, but do you deny my point that that's not
> reality?
I have never seen a setup where the client encoding did not come from the
default or the client (and the person who set it up knew what they were
doing). I don't think the other cases are worth optimizing.
From | Date | Subject | |
---|---|---|---|
Next Message | Joey K. | 2009-02-12 06:16:08 | Re: No MD5SUM for 8.1.16 RHEL5 rpms |
Previous Message | Bruce Momjian | 2009-02-12 03:18:08 | Re: Making a result of transaction visible to everyone, saving the ability for a rollback |