From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, 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 20:28:04 |
Message-ID: | m2fwh8uh4b.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
> 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.
In this case that would be an INSTEAD OF trigger, from which you can
call the original command with EXECUTE. You just have to protect
yourself against infinite recursion, but that's doable. See attached
example.
> 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.
CREATE TRIGGER se_permission_checks
INSTEAD OF COMMAND ALTER TABLE
EXECUTE PROCEDURE se_permission_checks_alter_table();
In this INSTEAD OF trigger, protect against recursion, EXECUTE the
original ALTER TABLE statement which is given to you as a parameter,
enable the command trigger again.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachment | Content-Type | Size |
---|---|---|
cmdtrigger.ext.sql | application/octet-stream | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Keller | 2011-11-28 21:12:36 | Re: odbc_fdw |
Previous Message | Merlin Moncure | 2011-11-28 20:25:05 | Re: patch for type privileges |