Re: [v9.3] OAT_POST_ALTER object access hooks

Sorry, I missed the attached version.
Please use this revision.

2012/11/15 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>

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