Horton

Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>, pgsql-bugs@lists.postgresql.org
Date: 2022-05-06T05:26:42Z
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

Attachments

On Wed, May 4, 2022 at 7:17 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2022-May-02, LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC wrote:
>
> > As stated in the documentation [1], creating an operator class without
> > specifying the FAMILY option will create an operator family with the same
> > name as the new class if it doesn't already exist. In this case, my event
> > trigger is activated through the "CREATE OPERATOR CLASS" tag as usual, but
> > pg_event_trigger_ddl_commands() still returns only one row - for the
> > operator class creation. I would have expected it to list the creation of
> > the operator family as well.
>
> I agree, this looks like an omission somewhere -- the extra object
> should have been reported.

Agreed.

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.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/