Re: [v9.3] OAT_POST_ALTER object access hooks

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [v9.3] OAT_POST_ALTER object access hooks
Дата
Msg-id CA+TgmobW49dcRMfbn+ExV_NdBc=b=EgNVQUOwdRbeTvwHAmXBQ@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  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
On Tue, Mar 12, 2013 at 11:53 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> The attached patch is rebased one towards the latest master.
> It newly added a hook being missed in the previous revision at ALTER
> EVENT TRIGGER ENABLE / DISABLE, and adjusted argument of
> finish_heap_swap() on REFRESH MATERIALIZED VIEW to handle
> it as internal operations.

Thanks.  I committed the backend portions of this, but not the sepgsql
and related documentation changes yet.  I made some improvements to
the comments along the way.  I am not entirely happy with the grotty
hack around ALTER COLUMN SET/DROP DEFAULT.  Is there a better
alternative?  Do we really need a hook there at all?

The one non-cosmetic change I made was to adjust slightly the firing
point in swap_relation_files.  It doesn't make any sense to me to
exclude pg_class here, rather arbitrarily, out of all objects in the
system.  This does to some degree raise the question more broadly: is
the point just after CatalogUpdateIndexes() the right rule for where
to put this hook?  But I've left it the way you have it for now.  Part
of me thinks that what you really want here is a pre-alter hook rather
than a post-alter hook...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Strange Windows problem, lock_timeout test request
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_test_fsync crashes on systems with POSIX signal handling