Re: Adding missing object access hook invocations - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Adding missing object access hook invocations
Date
Msg-id 20200419225546.GB436587@paquier.xyz
Whole thread Raw
In response to Re: Adding missing object access hook invocations  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Adding missing object access hook invocations  (Mark Dilger <mark.dilger@enterprisedb.com>)
Re: Adding missing object access hook invocations  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Thu, Mar 19, 2020 at 11:47:46AM -0700, Mark Dilger wrote:
> On Mar 19, 2020, at 11:30 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>>  Will post v3 shortly.

Thanks for sending a new version of the patch and removing the bits
about object drops.  Your additions to src/backend/ look fine to me,
so I have no objections to commit it.  The only module we have in core
that makes use of object_access_hook is sepgsql.  Adding support for
it could be done in a separate commit for AMs, stats and user mappings
but we would need a use-case for it.  One thing that I can see is that
even if we test for ALTER put_your_object_type_here foo RENAME TO in
the module and that your patch adds one InvokeObjectPostAlterHook()
for ALTER RULE, we don't have support for rules in sepgsql (see
sepgsql_object_access for OAT_POST_CREATE).  So that's fine.

Unfortunately, we are past feature freeze so this will have to wait
until v14 opens for business to be merged, and I'll take care of it.
Or would others prefer to not wait one extra year for those changes to
be released?

Please note that there is a commit fest entry, though you forgot to
add your name as author of the patch:
https://commitfest.postgresql.org/28/2513/
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: v13: Performance regression related to FORTIFY_SOURCE
Next
From: David Rowley
Date:
Subject: Re: Parallel Append can break run-time partition pruning