Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie(dot)lemaire(at)developpement-durable(dot)gouv(dot)fr>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
Date: 2022-05-19 08:56:09
Message-ID: YoYGKWWwrB+8AlV/@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, May 06, 2022 at 02:26:42PM +0900, Masahiko Sawada wrote:
> DefineOpClass() calls CreateOpFamily() to create the operator family
> but in CreateOpFamily() we don't report the new object to event
> triggers. The event by CREATE OPERATOR FAMILY is normally reported by
> ProcessUtilitySlow(). I've confirmed this happens on all supported
> branches. I've attached a patch to fix it.

Hmm. It looks like it makes sense to back-patch that. That's indeed
a bit surprising to not have an event trigger inform about both.

+-- CRAETE OPERATOR CLASS without FAMILY clause should report
+-- both CRAETE OPERATOR FAMILY and CRAETE OPERATOR CLASS
Got the same typo here, repeated three times.

- tmpAddr = CreateOpFamily(stmt->amname, opcname,
+ tmpAddr = CreateOpFamily(&opfstmt, stmt->amname, opcname,
namespaceoid, amoid);
CreateOpFamily() does not need its second argument now that you pass
down a CreateOpFamilyStmt as first argument, no?
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Lepikhov 2022-05-19 09:03:55 Re: Negative value of numGroups
Previous Message Michael Paquier 2022-05-19 08:02:32 Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY