Re: The ultimate extension hook. - Mailing list pgsql-hackers

From David Rowley
Subject Re: The ultimate extension hook.
Date
Msg-id CAApHDvoYtdkAe=-HE323SCvPzEkiSvnBd18WwNLu7pGUPOicqQ@mail.gmail.com
Whole thread Raw
In response to Re: The ultimate extension hook.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: The ultimate extension hook.  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
List pgsql-hackers
On Thu, 24 Sep 2020 at 16:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Wood <hexexpert@comcast.net> 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?

Well, Dan did mention other use cases.  It's certainly questionable if
people wanted to use it to invent their own message types as they'd
need client support.  However, when it comes to newly proposed hooks,
I thought we should be asking ourself questions like, are there
legitimate use cases for this?  Is it safe to expose this?  It seems a
bit backwards to consider illegitimate uses of a hook unless they
relate to security.

> I'm not really convinced that any of the specific use-cases you suggest
> are untenable to approach via the existing function fastpath mechanism,
> anyway.

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 possibilities here and make a judgement call based on if
any alternatives exist today that will allow that problem to be solved
sufficiently in another way.

David



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Missing TOAST table for pg_class
Next
From: legrand legrand
Date:
Subject: Re: [PATCH] Add features to pg_stat_statements