From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie(dot)lemaire(at)developpement-durable(dot)gouv(dot)fr> |
Cc: | 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-04 10:17:46 |
Message-ID: | 202205041017.uc3dxylntais@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Vejsada | 2022-05-04 13:05:32 | pg_upgrade (12->14) fails on aggregate |
Previous Message | Daniele Varrazzo | 2022-05-03 23:48:21 | Re: Types pollution with unknown oids and server-side parameters binding |