Re: Request for comment on setting binary format output per session

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Request for comment on setting binary format output per session
Дата
Msg-id 2510332.1681762946@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Request for comment on setting binary format output per session  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Request for comment on setting binary format output per session  (Robert Haas <robertmhaas@gmail.com>)
Re: Request for comment on setting binary format output per session  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Request for comment on setting binary format output per session
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: optimize several list functions with SIMD intrinsics