| 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: | Whole Thread | Raw Message | 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 |