Re: Middleware Messages for FE/BE - Mailing list pgsql-hackers

From Jesper Pedersen
Subject Re: Middleware Messages for FE/BE
Date
Msg-id 4dfa2b41-4678-7ec9-bea0-9114f8c0f7a9@redhat.com
Whole thread Raw
In response to Re: Middleware Messages for FE/BE  (Hannu Krosing <hannuk@google.com>)
Responses Re: Middleware Messages for FE/BE  (Simon Riggs <simon.riggs@enterprisedb.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Alexander Pyhalov
Date:
Subject: Re: Push down time-related SQLValue functions to foreign server
Next
From: Zhihong Yu
Date:
Subject: Re: Push down time-related SQLValue functions to foreign server