Re: Allow escape in application_name
От | Masahiko Sawada |
---|---|
Тема | Re: Allow escape in application_name |
Дата | |
Msg-id | CAD21AoDtrz5bWLJ5QvOoxpZg1ub=6k2qwP6F5yvfkH3YvF7M2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Allow escape in application_name (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: Allow escape in application_name
|
Список | pgsql-hackers |
On Tue, Dec 28, 2021 at 3:29 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: > > > > On 2021/12/28 9:32, Masahiko Sawada wrote: > > Doesn't this query return 64? So the expression "substring(str for > > (SELECT max_identifier_length FROM pg_control_init()))" returns the > > first 64 characters of the given string while the application_name is > > truncated to be 63 (NAMEDATALEN - 1) characters. It also seems to be > > fine to use current_setting('max_identifier_length') instead of > > max_identifier_length of pg_control_init(). > > Interesting! I agree that current_setting('max_identifier_length') should be used instead. Attached is the updated versionof the patch. It uses current_setting('max_identifier_length'). Thank you for updating the patch! It looks good to me. > > BTW it seems confusing that pg_control_init() (also pg_controldata) and GUC report different values as max_identifier_length.Probably they should return the same value such as NAMEDATALEN - 1. But this change might be overkill... Agreed. Probably we can fix it in a separate patch if necessary. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: