> On 10/23/2020 9:31 AM Jehan-Guillaume de Rorthais wrote:
> [...]
> * useless with encrypted traffic
>
> So, +1 for such hooks.
>
> Regards,
Ultimately Postgresql is supposed to be extensible.
I don't see an API hook as being some crazy idea even if some may not like what
I might want to use
On Thu, 24 Sep 2020 17:08:44 +1200
David Rowley wrote:
[...]
> I wondered if there was much in the way of use-cases like a traffic
> filter, or statement replication. I wasn't sure if it was a solution
> looking for a problem or not, but it seems like it could be productive
> to talk about
> On 09/23/2020 9:26 PM Tom Lane wrote:
> ...
> > The hook I'd like to see would be in the PostgresMain() loop
> > for the API "firstchar" messages.
>
> What, to invent your own protocol? Where will you find client libraries
> buying into that?
No API/client changes are needed for:
1)
On Thu, 24 Sep 2020 at 16:26, Tom Lane wrote:
>
> Daniel Wood writes:
> > Hooks exist all over PG for extensions to cover various specific usages.
> > The hook I'd like to see would be in the PostgresMain() loop
> > for the API "firstchar" messages.
>
> What, to invent your own protocol? Where
Daniel Wood writes:
> Hooks exist all over PG for extensions to cover various specific usages.
> The hook I'd like to see would be in the PostgresMain() loop
> for the API "firstchar" messages.
What, to invent your own protocol? Where will you find client libraries
buying into that?
I'm not
Hooks exist all over PG for extensions to cover various specific usages.
The hook I'd like to see would be in the PostgresMain() loop
for the API "firstchar" messages.
While I started just wanting the hook for the absolute minimum overhead to
execute a function, even faster than fastpath, and
