Re: BUG #6480: NLS text width problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #6480: NLS text width problem
Дата
Msg-id 23924.1331081368@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #6480: NLS text width problem  (Sergey Burladyan <eshkinkot@gmail.com>)
Ответы Re: BUG #6480: NLS text width problem  (Sergey Burladyan <eshkinkot@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Extension tracking temp table and causing update failure
Следующее
От: tatypr18@gmail.com
Дата:
Сообщение: BUG #6522: PostgreSQL does not start