[v9.3] OAT_POST_ALTER object access hooks

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: [v9.3] OAT_POST_ALTER object access hooks
Date: 2012-11-15 20:10:58
Message-ID: CADyhKSVx64GdFNKKUe=w7BD9sXr3i+NO2iHB47HPLQ_wLL-_Gw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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>

Attachment Content-Type Size
sepgsql-v9.3-post-alter-support.v1.patch application/octet-stream 92.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-11-15 20:15:24 Re: Timing events WIP v1
Previous Message Dimitri Fontaine 2012-11-15 20:09:34 Re: Dumping an Extension's Script