From: Roger Leigh on
On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote:
> On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> > Roger Leigh <rleigh(a)codelibre.net> writes:
> > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> > >> Elsewhere in the psql code, notably in mbprint.c, we make the decision
> > >> on whether to apply certain Unicode-aware processing based on whether
> > >> the client encoding is UTF8. The same should be done here.
> > >>
> > >> There is a patch somewhere in the pipeline that would automatically set
> > >> the psql client encoding to whatever the locale says, but until that is
> > >> done, the client encoding should be the sole setting that rules what
> > >> kind of character set processing is done on the client side.
> >
> > > OK, that makes sense to a certain extent. However, the characters
> > > used to draw the table lines are not really that related to the
> > > client encoding for data sent from the database (IMHO).
> >
> > Huh? The data *in* the table is going to be in the client_encoding, and
> > psql contains no mechanisms that would translate it to something else.
> > Surrounding it with decoration in a different encoding is just a recipe
> > for breakage.
>
> Ah, I was under the mistaken assumption that this was iconv()ed or
> otherwise translated for correct display. In that case, I'll leave
> the patch as is (using the client encoding for table lines).
>
> I've attached an updated copy of the patch (it just removes the
> now unneeded langinfo.h header).

This patch included a bit of code not intended for inclusion
(setting of client encoding based on locale), which the attached
(and hopefully final!) revision of the patch excludes.


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.
From: "Brad T. Sliger" on
On Tuesday 06 October 2009 11:35:03 Roger Leigh wrote:
> On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote:
> > On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> > > Roger Leigh <rleigh(a)codelibre.net> writes:
> > > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> > > >> Elsewhere in the psql code, notably in mbprint.c, we make the
> > > >> decision on whether to apply certain Unicode-aware processing based
> > > >> on whether the client encoding is UTF8. The same should be done
> > > >> here.
> > > >>
> > > >> There is a patch somewhere in the pipeline that would automatically
> > > >> set the psql client encoding to whatever the locale says, but until
> > > >> that is done, the client encoding should be the sole setting that
> > > >> rules what kind of character set processing is done on the client
> > > >> side.
> > > >
> > > > OK, that makes sense to a certain extent. However, the characters
> > > > used to draw the table lines are not really that related to the
> > > > client encoding for data sent from the database (IMHO).
> > >
> > > Huh? The data *in* the table is going to be in the client_encoding,
> > > and psql contains no mechanisms that would translate it to something
> > > else. Surrounding it with decoration in a different encoding is just a
> > > recipe for breakage.
> >
> > Ah, I was under the mistaken assumption that this was iconv()ed or
> > otherwise translated for correct display. In that case, I'll leave
> > the patch as is (using the client encoding for table lines).
> >
> > I've attached an updated copy of the patch (it just removes the
> > now unneeded langinfo.h header).
>
> This patch included a bit of code not intended for inclusion
> (setting of client encoding based on locale), which the attached
> (and hopefully final!) revision of the patch excludes.
>
>
> Regards,
> Roger

I looked at psql-utf8-table-9.patch.

It applies, builds and installs. `gmake check` passes and is not affected by values of LANG or LC_ALL in the
environment. HTML and man documentation builds and looks good. The patch doesn't introduce new lint.

The psql utility displays UTF8 line art when the client encoding is UTF8, and ASCII line art is displayed otherwise.
This can be overridden with `\pset linestyle ASCII` or `\pset linestyle UTF8`. The psql line art is no longer affected by
the values of LANG or LC_ALL in the environment.

As far as I can tell, everything looks reasonable.

Thanks,

--bts

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Eisentraut on
On Tue, 2009-10-06 at 19:35 +0100, Roger Leigh wrote:
> This patch included a bit of code not intended for inclusion
> (setting of client encoding based on locale), which the attached
> (and hopefully final!) revision of the patch excludes.

Well, the documentation still claims that this is dependent on the
locale. This should be updated to match the code.

I think the setting ought be called linestyle unicode (instead of utf8),
since the same setting would presumably work in case we ever implement
UTF-16 support on the client side.



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on
Peter Eisentraut <peter_e(a)gmx.net> wrote:

> I think the setting ought be called linestyle unicode (instead of
> utf8), since the same setting would presumably work in case we ever
> implement UTF-16 support on the client side.

Yeah, anytime one gets sloppy with the distinction between a character
set and a character encoding scheme, one tends to regret it, sooner or
later. Here's we're talking about which glyphs to show -- that's
based on a character set.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Roger Leigh on
On Fri, Oct 09, 2009 at 04:35:46PM -0500, Kevin Grittner wrote:
> Peter Eisentraut <peter_e(a)gmx.net> wrote:
>
> > I think the setting ought be called linestyle unicode (instead of
> > utf8), since the same setting would presumably work in case we ever
> > implement UTF-16 support on the client side.
>
> Yeah, anytime one gets sloppy with the distinction between a character
> set and a character encoding scheme, one tends to regret it, sooner or
> later. Here's we're talking about which glyphs to show -- that's
> based on a character set.

The attached updated patch renames all user-visible uses of
"utf8" to "unicode". It also updates the documentation
regarding "locale" to "psql client character set encoding"
so the docs now match the code exactly.


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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Prev: Hot Standby 0.2.1
Next: Rejecting weak passwords