From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz> |
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>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de> |
Subject: | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Date: | 2022-04-06 19:16:43 |
Message-ID: | 300712f85a30acecaa5c8f16c968b95537bfebd8.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2022-04-06 at 20:09 +0900, Michael Paquier wrote:
> > The current patch already handles NULL with a byte of overhead; is
> > there any advantage to using noError? (It might make things messier
> > once a second member gets added to the struct.) My concern was directed
> > at the GUC proposal.
>
> FWIW, I am a bit concerned by this approach because it feels
> inconsistent with any other conditional fields passed down from the
> parallel leader to its workers. And if we need to add more fields to
> ParallelProcInfo in the future, it will be cleaner to use different
> TOC keys to pass down different fields anyway, no?
I assumed that we would follow the existing model of "(de)serialize a
whole struct", rather than pulling it apart into many separate keys. If
it got too complicated then we could consider introducing a
SerializedParallelProcInfo struct like some of the other functions do.
Maybe that wouldn't work so well if many of the fields are strings?
Is there a significant cost to changing this later, if one approach
turns out to be wrong?
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2022-04-06 19:27:03 | Re: Kerberos delegation support in libpq and postgres_fdw |
Previous Message | Lukas Fittl | 2022-04-06 19:14:35 | Re: shared-memory based stats collector - v70 |