Re: Prep object creation hooks, and related sepgsql updates
От | Kohei KaiGai |
---|---|
Тема | Re: Prep object creation hooks, and related sepgsql updates |
Дата | |
Msg-id | CADyhKSVCqurJdOOOztkPa_cyDqXDieJBBk_9yKjrSNabLSW+1g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Prep object creation hooks, and related sepgsql updates (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Prep object creation hooks, and related sepgsql updates
|
Список | pgsql-hackers |
2011/11/28 Dimitri Fontaine <dimitri@2ndquadrant.fr>: > Kohei KaiGai <kaigai@kaigai.gr.jp> writes: >> How does it inherit an opaque private initialized at BEFORE trigger to >> AFTER trigger? I checked your patch, however, it seems to me it does >> not have a mechanism to deliver something between BEFORE and AFTER. > > Right, there's no such facility provided in there. But it seems to me > that your extension could attach some shared memory or use other > mechanisms to handle that on its own? > Hmm. If extension side manage the contextual information by itself, it seems to me feasible, although it is a bit bother. I found up a similar idea that acquires control on ProcessUtility_hook and save necessary contextual information on auto variable then kicks the original ProcessUtility_hook, then it reference the contextual information from object_access_hook. For example, we don't want to apply permission checks on new relations constructed with make_new_heap. It shall be invoked when CLUSTER, VACUUM or ALTER TABLE, so we can skip permission checks when the saved command tag indicates these commands are currently running. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: