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

On Tue, Jun 7, 2022 at 6:54 PM Jacob Champion <jchampion@timescale.com> wrote:
> "This struct contains connection fields that are explicitly safe for
> workers to access" _is_ a useful semantic, in my opinion. And it seems
> like it'd make it easier to determine what needs to be included in the
> struct; I'm not sure I follow why it would result in less consistency.
>
> But to your suggestion, if we just called the new struct
> "ClientConnectionInfo", would it be a useful step towards your
> proposed three-bucket state? I guess I'm having trouble understanding
> why a struct that is defined as "this stuff *doesn't* get serialized"
> is materially different from having one that's the opposite.

Well, it isn't, and if my proposal boils down to that, which perhaps
it does, then my proposal isn't that great, honestly. Let me try again
to explain, though, and maybe it will seem less arbitrary with a
second explanation -- or maybe it won't.

If we say "this struct contains authentication-related information
that we got from the client and which functions may want to look at
later," then I feel like the chances are good that when someone adds a
new thing to the system in the future, they will know whether or not
that new thing falls into that category or not. If the definition of a
struct is "everything that should be serialized," then I feel like the
chances are less good that everyone will know whether a new thing they
are adding falls into that category or not. Perhaps that is
ill-founded, but I don't think "should be serialized" is necessarily
something that everybody is going to have the same view on, or even
know what it means.

Also, I don't think we want to end up with a situation where we have a
struct that contains wildly unrelated things that all need to be
serialized. If the definition of the struct is "stuff we should
serialize and send to the worker," well then maybe the transaction
snapshot ought to go in there! Well, no. I mean, we already have a
separate place for that, but suppose somehow we didn't. It doesn't
belong here, because yes the things in this struct get serialized, but
it's not only any old thing that needs serializing, it's more specific
than that.

I guess what this boils down to is that I really want this thing to
have a meaningful name by means of which a future developer can make a
guess as to whether some field they're adding ought to go in there. I
theorize that SharedPort is not too great because (a) Port is already
a bad name and (b) how am I supposed to know whether my stuff ought to
be shared or not? I like something like ClientConnectionInfo better
because it seems to describe what the stuff in the struct *is* rather
than what we *do* with it.

-- 
Robert Haas
EDB: http://www.enterprisedb.com