On Fri, 20 Aug 2021 at 13:59, Jesper Pedersen
<jesper.pedersen@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/
