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).
But at least initially each middleware would process only it's own
class, so a single if() and not a big switch/case :)
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 .
-----
Hannu Krosing
Google Cloud - We have a long list of planned contributions and we are hiring.
Contact me if interested.
On Thu, Aug 19, 2021 at 8:29 PM Simon Riggs
<simon.riggs@enterprisedb.com> wrote:
>
> On Thu, 19 Aug 2021 at 19:04, Jesper Pedersen
> <jesper.pedersen@redhat.com> wrote:
>
> > Should the middleware guess the client driver based on the startup
> > message ? Or are you thinking about having a class identifier group for
> > each client driver and then a massive "switch/case" inside each middleware ?
>
> The question is how does a client communicate with middleware?
>
> The message that would be sent would relate to the features of the
> middleware, while being agnostic as to the client driver.
>
> --
> Simon Riggs http://www.EnterpriseDB.com/
>
>
