Re: [GENERAL] psql weird behaviour with charset encodings

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [GENERAL] psql weird behaviour with charset encodings
Дата
Msg-id CAB7nPqRd45bxnomsP6hq17Y0X5sscdyH-yHTZMbKtnkmORCSLg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] psql weird behaviour with charset encodings  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [GENERAL] psql weird behaviour with charset encodings
Список pgsql-hackers


On Tue, Jun 2, 2015 at 4:19 PM, Michael Paquier wrote:
On Sun, May 24, 2015 at 2:43 AM, Noah Misch wrote:
> It would be good to purge the code of precisions on "s" conversion specifiers,
> then Assert(!pointflag) in fmtstr() to catch new introductions.  I won't plan
> to do it myself, but it would be a nice little defensive change.

This sounds like a good protection idea, but as it impacts existing backend code relying in sprintf's port version we should only do the assertion in HEAD in my opinion, and mention it in the release notes of the next major version at the time a patch in this area is applied. I guess that we had better backpatch the places using .*s though on back-branches.

Attached is a patch purging a bunch of places from using %.*s, this will make the code more solid when facing non-ASCII strings. I let pg_upgrade and pg_basebackup code paths alone as it reduces the code lisibility by moving out of this separator. We may want to fix them though if file path names have non-ASCII characters, but it seems less critical.
Thoughts?
--
Michael
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: auto_explain sample rate
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1