Re: BUG #6480: NLS text width problem - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6480: NLS text width problem
Date
Msg-id 23924.1331081368@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6480: NLS text width problem  (Sergey Burladyan <eshkinkot@gmail.com>)
Responses Re: BUG #6480: NLS text width problem  (Sergey Burladyan <eshkinkot@gmail.com>)
List pgsql-bugs
Sergey Burladyan <eshkinkot@gmail.com> writes:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Can you prepare a patch?

> Surely, I was sent this patch to pgsql-hackers and added to the commitfest-next to
> be sure I'll never lost it https://commitfest.postgresql.org/action/patch_view?id=816

Hmm, this patch makes it obvious that the current incarnation of
pg_wcswidth has never worked.  Good thing it's been unused for the same
length of time :-(

> Unfortunately, I was sent it with content-disposition: inline by mistake, as
> result, web interface divided it by two independent parts. Also this patch for 9.1

I'm a bit nervous about the idea of back-patching this, as if there is
anything wrong with it it will break code that works perfectly fine for
most people.  Possibly more to the point, it is making assumptions about
the behavior of printf with %*s that I think are unportable.  Even
granted that libc is glibc, isn't this pretty much guaranteed to fail
if glibc's idea of the encoding is different from pset.encoding?

I think it'd be better to avoid depending on %*s for the data string
and instead use it (with appropriate adjustment of the calculation)
for the space-separator part of the format.  Since that's a constant
empty string, there shouldn't be any possibility of libc doing something
other than what we intend.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Extension tracking temp table and causing update failure
Next
From: tatypr18@gmail.com
Date:
Subject: BUG #6522: PostgreSQL does not start