> On 09/23/2020 9:26 PM Tom Lane <t...@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 the end.
Yes, (2) API extension "case 'A'" could be used to roll ones own protocol.
When pondering API hooking, in general, I thought of 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 the SQL 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 could do 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 others will think of things I
haven't even yet thought of that would leverage this.
- Dan Wood
