Re: [PATCH] Expose port->authn_id to extensions and triggers
От | Jacob Champion |
---|---|
Тема | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Дата | |
Msg-id | 214737816b45c29d4aea01ba161f0a2d7876432e.camel@vmware.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Expose port->authn_id to extensions and triggers (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Expose port->authn_id to extensions and triggers
|
Список | pgsql-hackers |
On Tue, 2022-03-29 at 16:53 -0700, Andres Freund wrote: > > We'd also need to guess whether the GUC system's serialization of NULL > > as an empty string is likely to cause problems for any future auth > > methods. > > You can't represent a NULL in a postgres 'text' datum, independent of > parallelism. So the current definition of pg_session_authn_id() already > precludes that (and set_authn_id() and ...). Honestly, I can't see a reason > why we should ever allow authn_id to contain a NULL byte. I don't mean a NULL byte, just a NULL pointer. This part of the implementation doesn't distinguish between it and an empty string: > /* NULL becomes empty string, see estimate_variable_size() */ > do_serialize(destptr, maxbytes, "%s", > *conf->variable ? *conf->variable : ""); Whether that's a problem in the future entirely depends on whether there's some authentication method that considers the empty string a sane and meaningful identity. We might reasonably decide that the answer is "no", but I like being able to make that decision as opposed to delegating it to an existing generic framework. (That last point may be my core concern about making it a GUC: I'd like us to have full control of how and where this particular piece of information gets modified.) Thanks, --Jacob
В списке pgsql-hackers по дате отправления: