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
|
Список | 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 по дате отправления: