On Thu, 19 Aug 2021 at 17:42, Jesper Pedersen
<jesper.pedersen@redhat.com> wrote:
> I would say that this is a PostgreSQL protocol v4 thing, as there is a
> bit more to it.
>
>
> There is a need to trigger middleware functionality, but you need to
> query the middleware stack first on what it supports - failover, load
> balancing, ... And, what type of language is that ? SQL query ? Not all
> middleware support general SQL queries.
Agreed. No part of my proposal mentioned SQL queries.
We need to be able to send the middleware a message. Replies can be
sent as NoticeResponse, if needed, which already exists.
If you want to invent a new grammar for your middleware, cool, I'm not
stopping you.
> Once you have established what is supported and what isn't you need the
> client driver (libpq is the very easy part) - so lets include Java, C#,
> Rust, golang, ... - to understand their environment to trigger the
> correct message in the configured scenario. F.ex. how is multiple
> application clusters connecting to the same middleware instance
> (connection pool) going to coordinate their 'M' message ?
Each component can speak to the middleware to discover that, if it
wishes. The middleware can coordinate.
> If you are looking to configure the middleware instance then we can just
> use the existing protocol with FE/Q;
Which is exactly the thing we already have and the very thing I said I
was trying to avoid.
> that said pgagroal has its own binary protocol for admin payload.
I want to empower all future middleware, not just support one. Perhaps
we can take code or ideas from pgagroal and put it in core? Please
explain the binary protocol some more.
> Could you expand on typical scenarios that you want to see implemented ?
I see this as a generalized interface that can be used for a great many things.
* Failover managers
* Load Balancers
* Routing agents
* Things I haven't thought of yet, but others may have
etc..
We are currently limited by the messages we can send efficiently.
--
Simon Riggs http://www.EnterpriseDB.com/
