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  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
Следующее
От: "tanghy.fnst@fujitsu.com"
Дата:
Сообщение: RE: row filtering for logical replication