Re: [v9.3] OAT_POST_ALTER object access hooks - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.3] OAT_POST_ALTER object access hooks
Date
Msg-id CA+TgmobW49dcRMfbn+ExV_NdBc=b=EgNVQUOwdRbeTvwHAmXBQ@mail.gmail.com
Whole thread Raw
In response to Re: [v9.3] OAT_POST_ALTER object access hooks  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.3] OAT_POST_ALTER object access hooks
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Strange Windows problem, lock_timeout test request
Next
From: Tom Lane
Date:
Subject: Re: pg_test_fsync crashes on systems with POSIX signal handling