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

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>
Cc: "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers
Date: 2022-03-30 16:02:09
Message-ID: 214737816b45c29d4aea01ba161f0a2d7876432e.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2022-03-30 16:03:08 Re: Printing backtrace of postgres processes
Previous Message Greg Stark 2022-03-30 15:53:52 Re: Printing backtrace of postgres processes