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.ri...@enterprisedb.com> wrote: > > On Thu, 19 Aug 2021 at 19:04, Jesper Pedersen > <jesper.peder...@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/ > >
