Hi Hannu,
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.
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 == ..., ...)
BE/?
Int32 - Length
Int32 - Capability type
Byte - Support (0 == No, 1 == Yes)
Byten - Additional information
None of the client driver interfaces (specification API, like JDBC) has
functionality for this currently, so the client would need to type cast
the interface in all cases in order to get access to the trigger method, say
org.postgresql.jdbc.PgConnection.failover()
There could be custom capability type codes that targets specific
middleware like Simon suggested.
But at least initially each middleware would process only it's own
class, so a single if() and not a big switch/case :)
With a defined baseline of capabilities the client drivers and
middleware wouldn't have to invent their own codes.
The things I talked about were some forward-looking proposals on how
to use this capability and that some of the messages may at some point
become used / usable by more than a single middleware component at
which point they should be standardised .
It would be good to see a PoC of one capability implemented from the
client to the middleware that deals with coordination at the client level.
Best regards,
Jesper
