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