Re: [v9.3] OAT_POST_ALTER object access hooks
От | Kohei KaiGai |
---|---|
Тема | Re: [v9.3] OAT_POST_ALTER object access hooks |
Дата | |
Msg-id | CADyhKSX8SSYi4+UDX4X4XQPpX4FX84wZMn8G0p49Y2hhEnFu-w@mail.gmail.com обсуждение исходный текст |
Ответ на | [v9.3] OAT_POST_ALTER object access hooks (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [v9.3] OAT_POST_ALTER object access hooks
|
Список | 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>
Вложения
В списке pgsql-hackers по дате отправления: