Horton

Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-20T08:51:22Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix DDL deparse of CREATE OPERATOR CLASS

  2. Backpatch regression tests added by 2d689babe3cb

On Thu, May 19, 2022 at 2:26 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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.
>

Yeah, I also don't see a reason to not backpatch this.

>  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?
>

Right, apart from the patch looks good to me.

-- 
With Regards,
Amit Kapila.