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-29 16:42:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2011/11/28 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
> 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.
Hmm... In my case, it does not need to depend on the command trigger.
Let's see the attached patch; that hooks ProcessUtility_hook by
sepgsql_utility_command, then it saves contextual information on auto

The object_access_hook with OAT_POST_CREATE shall be invoked
from createdb() that was also called by standard_ProcessUtility.
In this context, sepgsql_database_post_create can reference
a property that is not contained withint pg_database catalog
(name of the source database).

At least, it may be able to solve my issues on hooks around object
creation time.

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Attachment: pgsql-v9.2-prep-creation-hook-part-1.v2.database.patch
Description: application/octet-stream (10.5 KB)

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-11-29 16:50:28
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Previous:From: Jaime CasanovaDate: 2011-11-29 16:11:25
Subject: Re: DOMAINs and CASTs

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