On Mon, Jun 6, 2022 at 11:44 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I think I'd feel more comfortable here if we were defining what went
> into which struct on some semantic basis rather than being like, OK,
> so all the stuff we want to serialize goes into struct #1, and the
> stuff we don't want to serialize goes into struct #2. I suppose if
> it's just based on whether or not we want to serialize it, then the
> placement of future additions will just be based on how people happen
> to feel about the thing they're adding right at that moment, and there
> won't be any consistency.
"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.
Thanks,
--Jacob