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

Re: Prep object creation hooks, and related sepgsql updates

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 (view raw or flat)
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: cmdtrigger.ext.sql
Description: application/octet-stream (1.2 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Stefan KellerDate: 2011-11-28 21:12:36
Subject: Re: odbc_fdw
Previous:From: Merlin MoncureDate: 2011-11-28 20:25:05
Subject: Re: patch for type privileges

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