> On 09/23/2020 9:26 PM Tom Lane <tgl@sss.pgh.pa.us> 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) API tracing/filtering; or
3) custom SQL like commands through a trivial modification to Simple Query 'Q'. Purely optional as you'll see at
theend.
Yes, (2) API extension "case 'A'" could be used to roll ones own protocol. When pondering API hooking, in general, I
thoughtof this also but don't let it be a distraction.
> 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.
Certainly (3) is just a command level way to execute a function instead of 'select myfunc()'. But it does go through
theSQL machinery and SQL argument type lookup and processing. I like fast and direct things. And (3) is so trivial to
implement.
However, even fastpath doesn't provide a protocol hook function where tracing could be done. If I had that alone I
coulddo my own 'Q' hook and do the "!cmd" processing in my extension even if I sold the idea just based on
tracing/filtering.
We hook all kinds of things in PG. Think big. Why should the protocol processing not have a hook? I'll bet some
otherswill think of things I haven't even yet thought of that would leverage this.
- Dan Wood