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

From Mark Dilger
Subject Re: Adding missing object access hook invocations
Date
Msg-id 0D4B1D4A-1656-4450-9313-2B83D360940F@enterprisedb.com
Whole thread Raw
In response to Re: Adding missing object access hook invocations  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers

> On Apr 19, 2020, at 3:55 PM, Michael Paquier <michael@paquier.xyz> wrote:
>
> 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?

I don't intend to make any special pleading for this to go in after feature freeze.  Let's see if others feel
differently.

Thanks for the review!

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: [PATCH] Small optimization across postgres (remove strlenduplicate usage)
Next
From: Tomas Vondra
Date:
Subject: Re: sqlsmith crash incremental sort