Re: [v9.3] OAT_POST_ALTER object access hooks
От | Robert Haas |
---|---|
Тема | Re: [v9.3] OAT_POST_ALTER object access hooks |
Дата | |
Msg-id | CA+Tgmoaf__+SrD-h2FkTVrJEkbW+vFX96GBm2-JJXyVGMQavNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [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 |
On Mon, Dec 3, 2012 at 9:59 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > As we discussed before, it is hard to determine which attributes shall > be informed to extension via object_access_hook, so the proposed > post-alter hook (that allows to compare older and newer versions) > works fine on 99% cases. > However, I'm inclined to handle SET TABLESPACE as an exception > of this scenario. For example, an idea is to define OAT_PREP_ALTER > event additionally, but only invoked very limited cases that takes > unignorable side-effects until system catalog updates. > For consistency of hook, OAT_POST_ALTER event may also ought > to be invoked just after catalog updates of pg_class->reltablespace, > but is_internal=true. > > How about your opinion? I don't really like it - I think POST should mean POST. You can define some other hook that gets called somewhere else, but after means after. There are other plausible uses of these hooks besides sepgsql; for example, logging the completion time of an action. Putting the hooks in the "wrong" places because that happens to be more convenient for sepgsql is going to render them useless for any other purpose. Maybe nobody else will use them anyway, but I'd rather not render it impossible before we get off the ground. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: