On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Anyway, that patch to set the client encoding automatically from the
> > locale sounds even more useful now.
>
> I think you're being overoptimistic to assume that that's going to
> eliminate the issue. It might patch things for Oleg's particular
> configuration; but the real problem IMO is that people are depending
> on ~/.psqlrc to set encoding/locale related behavior, and that file
> isn't read before executing -l/-c (not to mention -X).
>
> I wonder whether the most prudent solution wouldn't be to prevent
> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
This problem is caused when there's a mismatch between the
client encoding and the user's locale. We can detect this at
runtime and fall back to ASCII if we know they are incompatible.
Why don't we combine the two approaches we looked at so far:
1) The PG client encoding is UTF-8
2) The user's locale codeset (from nl_langinfo(CODESET)) is UTF-8
If *both* the conditions are satisfied simultaneously then we
are guaranteed that things will display correctly given what
the user has told us they wanted. If only one is satisfied then
we remain using ASCII and problems such as the non-UTF-8-locale
mis-display seen here are avoided, while still allowing Unicode
display for users who have a UTF-8 locale as well as a UTF-8
client encoding (such as myself ;-)
This should be a one-liner patch to update the existing check.
Regards,
Roger
-- .''`. Roger Leigh: :' : Debian GNU/Linux http://people.debian.org/~rleigh/`. `' Printing on
GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
