On Wed, Nov 25, 2009 at 11:34:35PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > The following patch adds in an nl_langinfo(CODESET) check in
> > addition to the existing client encoding check.
>
> I think the consensus is pretty clear that we should just set the
> default linestyle to ascii a
Roger Leigh writes:
> The following patch adds in an nl_langinfo(CODESET) check in
> addition to the existing client encoding check.
I think the consensus is pretty clear that we should just set the
default linestyle to ascii and not try to be cute with it. (I had
already committed a patch to th
On Wed, Nov 25, 2009 at 09:39:32AM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
> >> I think you're being overoptimistic to assume that that's going to
> >> eliminate the issue. It might patch things for Oleg's particular
> >> configurat
Andrew Dunstan wrote:
On Wed, November 25, 2009 10:04 am, Tom Lane wrote:
I'm now pretty well convinced that this patch is *not* worth the amount
of pain it will cause if it's invoked by default, no matter what
restrictions we try to place on that. We should just make the default
be linestyle=
On Wed, November 25, 2009 10:04 am, Tom Lane wrote:
> I'm now pretty well convinced that this patch is *not* worth the amount
> of pain it will cause if it's invoked by default, no matter what
> restrictions we try to place on that. We should just make the default
> be linestyle=ascii, period.
>
Magnus Hagander writes:
> On Wed, Nov 25, 2009 at 15:41, Tom Lane wrote:
>> Magnus Hagander writes:
>>> FWIW, this patch also *completely* breaks the default windows
>>> installs, which will have the database in UTF-8 but there is *never*
>>> any UTF-8 support on the console (only UTF-16).
>>
>
On Wed, Nov 25, 2009 at 15:41, Tom Lane wrote:
> Magnus Hagander writes:
>> FWIW, this patch also *completely* breaks the default windows
>> installs, which will have the database in UTF-8 but there is *never*
>> any UTF-8 support on the console (only UTF-16).
>
> Hmm ... so how do we work with u
Magnus Hagander writes:
> FWIW, this patch also *completely* breaks the default windows
> installs, which will have the database in UTF-8 but there is *never*
> any UTF-8 support on the console (only UTF-16).
Hmm ... so how do we work with utf-8 data in the database? That
should be the same case
Peter Eisentraut writes:
> On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
>> 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 ~/.
On Tue, Nov 24, 2009 at 22:35, Tom Lane wrote:
> Oleg Bartunov writes:
>> what's benefit of using linestyle=unicode ? I like old ASCII style
>> for console.
>
> Well, I have to grant that it looks pretty spiffy on a unicode-enabled
> display. Whether that's enough reason to risk breaking things
On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
> 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 re
On ons, 2009-11-25 at 00:14 +, Roger Leigh wrote:
> For the specific case here, where the locale is KOI8-R, we can
> determine at runtime that this isn't a UTF-8 locale and stay
> using ASCII. I'll be happy to send a patch in to correct this
> specific case.
There is already a proposed patch
On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
> I wonder whether the most prudent solution wouldn't be to prevent
> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
More generally, it would probably be safer if we used linestyle=unicode
only if the client encoding has been set
On Tue, Nov 24, 2009 at 05:43:00PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> >> I wonder whether the most prudent solution wouldn't be to prevent
> >> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
>
> > This prob
Roger Leigh writes:
> On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
>> 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 an
On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> Peter Eisentraut 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 m
On Tue, Nov 24, 2009 at 4:49 PM, Oleg Bartunov wrote:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>
>> Oleg Bartunov writes:
>>>
>>> what's benefit of using linestyle=unicode ? I like old ASCII style
>>> for console.
>>
>> Well, I have to grant that it looks pretty spiffy on a unicode-enabled
>> displ
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
what's benefit of using linestyle=unicode ? I like old ASCII style
for console.
Well, I have to grant that it looks pretty spiffy on a unicode-enabled
display. Whether that's enough reason to risk breaking things for
people with non
Oleg Bartunov writes:
> what's benefit of using linestyle=unicode ? I like old ASCII style
> for console.
Well, I have to grant that it looks pretty spiffy on a unicode-enabled
display. Whether that's enough reason to risk breaking things for
people with non-unicode-enabled displays is certainly
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
why 8.4 has no real problem ?
Because we never tried to use utf8 table decoration before. This
is collateral damage from Roger Leigh's recent patches.
The problem is evidently that Oleg is depending on ~/.psqlrc to
set client_enco
Peter Eisentraut 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 pr
On tis, 2009-11-24 at 21:55 +0300, Oleg Bartunov wrote:
> > Seems like a mismatch between client encoding and actual locale
> > environment.
>
> why 8.4 has no real problem ?
Because table formatting with Unicode characters is a new feature.
Anyway, that patch to set the client encoding automat
Oleg Bartunov writes:
> why 8.4 has no real problem ?
Because we never tried to use utf8 table decoration before. This
is collateral damage from Roger Leigh's recent patches.
The problem is evidently that Oleg is depending on ~/.psqlrc to
set client_encoding the way he wants it, but that file
On Tue, 24 Nov 2009, Peter Eisentraut wrote:
On tis, 2009-11-24 at 21:32 +0300, Oleg Bartunov wrote:
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
yes, I'm
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
What's your locale environment? ("env | grep ^L" would help.)
LC_COLLATE=ru_RU.KOI8-R
LANG=C
LC_CTYPE=ru_RU.KOI8-R
Hmm, I can duplicate the fact that psql -l uses utf8 characters
(because it
On tis, 2009-11-24 at 21:32 +0300, Oleg Bartunov wrote:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>
> > Oleg Bartunov writes:
> >> On Tue, 24 Nov 2009, Tom Lane wrote:
> >>> Hm, you only see it for -l and not for all tabular output? That's
> >>> a bit strange.
> >
> >> yes, I'm surprising myself. T
Oleg Bartunov writes:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>> What's your locale environment? ("env | grep ^L" would help.)
> LC_COLLATE=ru_RU.KOI8-R
> LANG=C
> LC_CTYPE=ru_RU.KOI8-R
Hmm, I can duplicate the fact that psql -l uses utf8 characters
(because it connects to the postgres DB which
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
yes, I'm surprising myself. Teodor has no problem, but he is under FreeBSD,
while I use slackware linux. Here is
Oleg Bartunov writes:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>> Hm, you only see it for -l and not for all tabular output? That's
>> a bit strange.
> yes, I'm surprising myself. Teodor has no problem, but he is under FreeBSD,
> while I use slackware linux. Here is ldd output.
What's your local
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
I have problem with CVS HEAD (noticed a week or so ago) -
psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
instead that ascii characters.
Hm, you only see it for -l and not for all tabular output? That's
a bit str
Oleg Bartunov writes:
> I have problem with CVS HEAD (noticed a week or so ago) -
> psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
> instead that ascii characters.
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
rega
31 matches
Mail list logo
