On Mon, 17 Apr 2023 at 16:22, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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.
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. > 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. Fwiw I've had at least two miniprojects that would eventually have led to protocol extensions. Like most of my projects they're not finished but one day... Progress reporting on queries in progress -- I had things hacked to send the progress report in an elog but eventually it would have made sense to put it in a dedicated message type that the client would know the structure of the content of. Distributed tracing -- to pass the trace span id for each query and any other baggage. Currently people either stuff it in application_id or in SQL comments but they're both pretty awful. -- greg
