Re: The ultimate extension hook.
От | Daniel Wood |
---|---|
Тема | Re: The ultimate extension hook. |
Дата | |
Msg-id | 474049858.67831.1600926053256@connect.xfinity.com обсуждение исходный текст |
Ответ на | Re: The ultimate extension hook. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: