Skip site navigation (1) Skip section navigation (2)

Re: Prep object creation hooks, and related sepgsql updates

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Prep object creation hooks, and related sepgsql updates
Date: 2011-11-28 17:00:45
Message-ID: CADyhKSVCqurJdOOOztkPa_cyDqXDieJBBk_9yKjrSNabLSW+1g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2011/11/28 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>

In response to

Responses

pgsql-hackers by date

Next:From: Gurjeet SinghDate: 2011-11-28 17:20:58
Subject: Re: psql line number reporting from stdin
Previous:From: Bruce MomjianDate: 2011-11-28 16:33:14
Subject: Re: pgsql: Make pg_dumpall build with the right object files under MSVC.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group