Re: encoding of PostgreSQL messages

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.

In response to

Responses

Browse pgsql-general by date

  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