[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: [HACKERS] set_client_encoding is broken
From: Tom Lane <tgl () sss ! pgh ! pa ! us>
Date: 2009-08-31 19:59:40
Message-ID: 23284.1251748780 () sss ! pgh ! pa ! us
[Download RAW message or body]
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Tom Lane píše 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic