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