Re: [v9.3] OAT_POST_ALTER object access hooks - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: [v9.3] OAT_POST_ALTER object access hooks
Date
Msg-id CADyhKSX8SSYi4+UDX4X4XQPpX4FX84wZMn8G0p49Y2hhEnFu-w@mail.gmail.com
Whole thread Raw
In response to [v9.3] OAT_POST_ALTER object access hooks  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.3] OAT_POST_ALTER object access hooks  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Sorry, I missed the attached version.
Please use this revision.

2012/11/15 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> The attached patch adds a new event type of object_access_hook;
> named OAT_POST_ALTER. As literal, it allows extensions to catch
> controls just after system catalogs are updated.
> It also adds sepgsql permission check capability on some ALTER
> commands, but not any.
>
> The hooks are designed to locate between heap update's and next
> command-counter increment, to allow extensions to reference
> both of older and newer version of catalog entry.
> Unless CCI is called, we can reference older one with SnapshotNow,
> and newer one with SnapshotSelf, as attached sepgsql code doing
> to detect namespace / name changes.
> As we discussed before, it is a significant point to pick-up which
> information should be delivered to extensions through the hooks,
> to avoid design too specific for a particular extension's requirement.
> I believe it is the best way to inform which fields were updated on
> the relevant ALTER command.
>
> The OAT_POST_ALTER can take two arguments. The one is
> "is_internal" flag similar to DROP or POST_CREATE hook.
> The other is "auxiliary_id" field to identify a particular entry of
> the catalog that takes a couple of IDs; E.g, pg_db_role_setting
> or pg_inherits.
>
> It might be noticed that some OAT_POST_CREATE hooks are
> also added on the code path being invoked on some ALTER
> commands, such as StoreAttrDefault, storeOperators or
> storeProcedures. These routines insert / delete subsidiary
> objects of others, but the "main" object is not touched in this
> code path. So, it makes hard to inform what was updated in
> this operation without these additional OAT_POST_CREATE.
>
> Regarding to sepgsql portion, I added logic to check "setattr"
> permission of only "main" object to simplify the patch.
> Later, I will also add logic for subsidiary objects like triggers
> or rules towards relation.
>
> Thanks,
> --
> KaiGai Kohei <kaigai@kaigai.gr.jp>



--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: add -Wlogical-op to standard compiler options?
Next
From: Darren Duncan
Date:
Subject: Re: feature proposal - triggers by semantics