Re: Request for comment on setting binary format output per session - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Request for comment on setting binary format output per session
Date
Msg-id 2510332.1681762946@sss.pgh.pa.us
Whole thread Raw
In response to Re: Request for comment on setting binary format output per session  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Request for comment on setting binary format output per session
Re: Request for comment on setting binary format output per session
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Apr 17, 2023 at 1:55 PM Jeff Davis <pgsql@j-davis.com> wrote:
>> Maybe we should have a single new message type 'x' to indicate a
>> message for a protocol extension, and then have a sub-message-type? It
>> might make error handling better for unexpected messages.

> ...
> The point of this thought experiment is to help us estimate how
> careful we need to be.

I tend to agree with the proposition that we aren't going to add new
message types very often, as long as we're careful to make them general
purpose.  Don't forget that adding a new message type isn't just a matter
of writing some spec text --- there has to be code backing it up.  We
will never introduce thousands of new message types, or if we do,
somebody factored it wrong and put data into the type code.

The fact that we've gotten away without adding *any* new message types
for about twenty years suggests to me that the growth rate isn't such
that we need sub-message-types yet.  I'd keep the structure the same
until such time as we can't choose a plausible code value for a new
message, and then maybe add the "x-and-subtype" convention Jeff suggests.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Request for comment on setting binary format output per session
Next
From: Nathan Bossart
Date:
Subject: Re: optimize several list functions with SIMD intrinsics