From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Dave Cramer <davecramer(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Request for comment on setting binary format output per session |
Date: | 2023-04-19 13:24:14 |
Message-ID: | CA+TgmoY6qV3VVVdMqE3=uyc9AOKeSdfD6q-1JVrFm9tLm8j5gA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 18, 2023 at 3:54 PM Greg Stark <stark(at)mit(dot)edu> wrote:
> Well the way I understood Robert's proposal would be that you would
> set a protocol option which could be some name like
> SuperDuperExtension and then later send an extended message like X
> SuperDuper Extension ...
>
> The point being not so much that it saves on message types but that it
> becomes possible for the wire protocol code to recognize the message
> type and know which extension's code to call back to. Presumably a
> callback was registered when the option was negotiated.
That's not what I was talking about. I meant extending the protocol in
core, and dealing with version differences between the client and the
server, not loading extensions that extend the protocol. Such a thing
could possibly be done, but it seems fairly tricky to make useful.
Defining the message format is just a small part of the problem. If
for example the message is one to be sent from server to client, you
need a server side hook that's called at the right point to allow you
to inject those messages, and then you need something on the libpq
side to, I guess, intercept those messages and call a user-defined
handler when they show up. It might make sense for things like
progress reporting and tracing to piggyback on e.g. NoticeResponse,
which already has existing libpq-side handling, rather than inventing
something altogether new. Or if we are going to invent something new,
say because we want to send structured data rather than a string, then
we invent one new message type for that which can be used by multiple
facilities e.g. StructuredNoticeResponse with a content-type (e.g.
json) and a payload.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Zhijie Hou (Fujitsu) | 2023-04-19 13:55:11 | RE: Support logical replication of DDLs |
Previous Message | Robert Haas | 2023-04-19 13:09:52 | Re: constants for tar header offsets |