On Fri, 20 Aug 2021 at 13:59, Jesper Pedersen <jesper.peder...@redhat.com> wrote: > > On 8/19/21 3:52 PM, Hannu Krosing wrote: > > Jesper, please don't confuse my ramblings with Simon's initial proposal. > > > > As I understand, the original proposal was just about adding a new > > wire protocol message type, which then could be used for emitting > > custom messages by middleware support extension - likely loaded as a > > preloaded shared library - and consumed by some middleware, which > > could either be some proxy or connection pooler or something compiled > > as part of the libpq, JDBC or other client driver. So it was just > > about providing extensibility to the protocol (the same way almost > > everything else in PostgreSQL is extensible). > > > > Yeah, but it is a change to the protocol which means that the client > drivers and middleware ecosystem needs to be updated to support that > message.
No, because FE messages don't need to be handled by the client, they just send them. It is the server that needs to be updated to understand that these messages might be received and to ignore them, which is simple enough. If a client doesn't know about a message it COULD send, but doesn't, then there is no update required. > So, if the message was added to the protocol we could add another > message with the response to the request and make the protocol stricter, say > > FE/M > Int32 - Length > Int16 - Request type (0 == Query capability, 1 == Execute capability) > Int32 - Capability type (0 == Failover, 1 == ..., ...) This much detail is optional. It is up to the middleware to define if it supports capability requests, or how it handles requests that it cannot satisfy. I'm trying to come up with something generic that people can use for decades to come, not restrict their choices to a very small subset based upon our current vision. > BE/? > Int32 - Length > Int32 - Capability type > Byte - Support (0 == No, 1 == Yes) > Byten - Additional information If we add a new message from BE, then yes, we need to modify all drivers, which would be an immediate fail for this proposal. The message replies you foresee are optional; they are not required by all middleware. I've already suggested you use NoticeResponse, which is already defined to ignore unknown field types, so is suitable and extensible. We could add a new field type of 'm' to represent a message sent from middleware to the client. -- Simon Riggs http://www.EnterpriseDB.com/
