Re: [PATCH] Expose port->authn_id to extensions and triggers
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: [PATCH] Expose port->authn_id to extensions and triggers |
| Дата | |
| Msg-id | YvjHFPs2yEDiMLVU@paquier.xyz обсуждение исходный текст |
| Ответ на | 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 Fri, Aug 12, 2022 at 03:34:04PM +0200, Drouvot, Bertrand wrote:
> 3)
>
> +SerializeClientConnectionInfo(Size maxsize, char *start_address)
> +{
> + /*
> + * First byte is an indication of whether or not authn_id has been
> set to
> + * non-NULL, to differentiate that case from the empty string.
> + */
>
> is authn_id being an empty string possible?
I don't recall that this can be the case yet, but we cannot discard
it. 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.
--
Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера