Re: [PATCH] Expose port->authn_id to extensions and triggers

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: [PATCH] Expose port->authn_id to extensions and triggers
Дата
Msg-id CAAWbhmgJ-5YHyOO4ioa-q1bDRexiwMBFru6jJVmV+ShUx_0yeQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Expose port->authn_id to extensions and triggers  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Ответы Re: [PATCH] Expose port->authn_id to extensions and triggers
Список pgsql-hackers
On Tue, Aug 16, 2022 at 2:02 AM Drouvot, Bertrand <bdrouvot@amazon.com> wrote:
> On 8/14/22 11:57 AM, Michael Paquier wrote:
> >    One thing was itching me about the serialization and
> > deserialization logic though: could it be more readable if we used an
> > intermediate structure to store the length of the serialized strings?
> > We use this approach in other areas, like for the snapshot data in
> > snapmgr.c.  This would handle the case of an empty and NULL string, by
> > storing -1 as length for NULL and >= 0 for the string length if there
> > is something set, while making the addition of more fields a
> > no-brainer.
>
> I think that's a good idea and I think that would be more readable (as
> compare to storing a "hint" in the first byte).

Sounds good. v3, attached, should make the requested changes:
- declare `struct ClientConnectionInfo`
- use an intermediate serialization struct
- switch to length-"prefixing" for the string

I do like the way this reads compared to before.

Thanks,
--Jacob

Вложения

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

Предыдущее
От: Jacob Champion
Дата:
Сообщение: Re: SYSTEM_USER reserved word implementation
Следующее
От: vignesh C
Дата:
Сообщение: Re: Column Filtering in Logical Replication