On Tue, Apr 18, 2023 at 3:54 PM Greg Stark <stark@mit.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