Skip site navigation (1) Skip section navigation (2)

Re: set_client_encoding is broken

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: set_client_encoding is broken
Date: 2009-08-31 19:59:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Tom Lane pe v po 31. 08. 2009 v 11:00 -0400:
>> I'm leaning to the third choice, but I wonder if anyone has any
>> comments or better ideas.

> It seems to me that 3 is OK.

> Another possibility is that InitPostgres can only fill up rel cache and
> GUC processing can stay on the same place. But in general, this problem
> can affect any other GUC variable which has assign hook and needs to
> lookup. 

Yeah, if it was *only* client_encoding then I wouldn't mind a hack
solution too much, but search_path is similarly affected and it's not
hard to foresee other GUCs in future that might require catalog access.
So I'd prefer a reasonably clean solution.

> I don't know how it works before, but I'm afraid that user can get error
> message in server encoding before it is correctly set.

It's always been the case that messages could come out before we can set
client_encoding.  I believe we have things set up so that you'll get the
untranslated, plain-ASCII-English message in that situation.  Feel free
to test ;-)

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-08-31 20:05:56
Subject: Re: Linux LSB init script
Previous:From: Kevin GrittnerDate: 2009-08-31 19:56:35
Subject: Re: Linux LSB init script

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group