From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kohei KaiGai <kaigai(at)heterodb(dot)com>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com> |
Subject: | Re: Adding missing object access hook invocations |
Date: | 2020-03-17 00:58:51 |
Message-ID: | 5D5F4853-B505-46F1-B153-89F132761223@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mar 16, 2020, at 5:14 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> On 2020-Mar-16, Mark Dilger wrote:
>
>> Hackers,
>>
>> While working on object access hooks, I noticed several locations where I would expect the hook to be invoked, but no actual invocation. I think this just barely qualifies as a bug. It's debatable because whether it is a bug depends on the user's expectations and whether not invoking the hook in these cases is defensible. Does anybody have any recollection of an intentional choice not to invoke in these locations?
>
> Hmm, possibly the create-time calls are missing.
It looks to me that both the create and alter calls are missing.
>
> I'm surprised about the InvokeObjectDropHook calls though. Doesn't
> deleteOneObject already call that? If we have more calls elsewhere,
> maybe they are redundant. I think we should only have those for
> "shared" objects.
Yeah, you are right about the drop hook being invoked elsewhere for dropping ACCESS METHOD and STATISTICS. Sorry for the noise.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-03-17 01:38:50 | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction |
Previous Message | Nikita Glukhov | 2020-03-17 00:55:06 | Re: SQL/JSON: functions |