pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedImplicitly created operator family not listed by pg_event_trigger_ddl_commands
13+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2022-05-20 6029861916 6c6ea6ea81 70f70d7d3f 3753a169e1 58b088a9b3 4492e73a66 Fix DDL deparse of CREATE OPERATOR CLASS
2022-05-20 ac78cec981 fa51cc86c6 daf015fd0c 99867e7277 Backpatch regression tests added by 2d689babe3cb
* Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-02 11:27 LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>
0 siblings, 1 reply; 13+ messages in thread
From: LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC @ 2022-05-02 11:27 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
Hi,
I have an event trigger firing at command end on "CREATE OPERATOR
CLASS", "CREATE OPERATOR FAMILY" and every other creation command of
schema dependent objects.
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.
Since event triggers don't catch implicit commands [2], the "CREATE
OPERATOR FAMILY" tag is useless here and the operator family creation is
never detected.
I observed this with PostgreSQL 14.2 (Windows 10, Visual C++ build 1914,
64-bit) and PostgreSQL 10.12 (Windows 10, Visual C++ build 1800,
64-bit), so it's likely not a version specific issue.
The documentation doesn't say much about pg_event_trigger_ddl_commands()
[3], but I would assume it's meant to be as exhaustive as possible,
hence this bug report. By comparison, with an event trigger firing at
command end on "CREATE TABLE" and a command such as "CREATE TABLE
my_table (id serial PRIMARY KEY)", pg_event_trigger_ddl_commands() would
return four rows, including the sequence creation and the index
creation.
Thanks in advance and sorry if I'm just missing something here.
Regards,
[1] https://www.postgresql.org/docs/14/sql-createopclass.html
[2] I don't think it's documented anywhere, but this seems to be a
consistant behaviour and it makes sense as long as
pg_event_trigger_ddl_commands() does the work.
[3] https://www.postgresql.org/docs/14/functions-event-triggers.html
--
Leslie Lemaire
Secrétariat général des ministères de la transition écologique, de la
cohésion des territoires et de la mer
Service du numérique
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-04 10:17 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>
0 siblings, 1 reply; 13+ messages in thread
From: Alvaro Herrera @ 2022-05-04 10:17 UTC (permalink / raw)
To: LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; +Cc: pgsql-bugs@lists.postgresql.org
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/
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-06 05:26 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 13+ messages in thread
From: Masahiko Sawada @ 2022-05-06 05:26 UTC (permalink / raw)
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
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/
Attachments:
report_create_opfamily_event_on_opclass_creation.patch (application/octet-stream, 4.8K) download
diff --git a/src/backend/commands/opclasscmds.c b/src/backend/commands/opclasscmds.c
index 66987966b4..107b707e6e 100644
--- a/src/backend/commands/opclasscmds.c
+++ b/src/backend/commands/opclasscmds.c
@@ -240,7 +240,8 @@ get_opclass_oid(Oid amID, List *opclassname, bool missing_ok)
* Caller must have done permissions checks etc. already.
*/
static ObjectAddress
-CreateOpFamily(const char *amname, const char *opfname, Oid namespaceoid, Oid amoid)
+CreateOpFamily(CreateOpFamilyStmt *stmt, const char *amname, const char *opfname,
+ Oid namespaceoid, Oid amoid)
{
Oid opfamilyoid;
Relation rel;
@@ -312,6 +313,10 @@ CreateOpFamily(const char *amname, const char *opfname, Oid namespaceoid, Oid am
/* dependency on extension */
recordDependencyOnCurrentExtension(&myself, false);
+ /* Report the new operator family to possibly interested event triggers */
+ EventTriggerCollectSimpleCommand(myself, InvalidObjectAddress,
+ (Node *) stmt);
+
/* Post creation hook for new operator family */
InvokeObjectPostCreateHook(OperatorFamilyRelationId, opfamilyoid, 0);
@@ -447,12 +452,17 @@ DefineOpClass(CreateOpClassStmt *stmt)
}
else
{
+ CreateOpFamilyStmt opfstmt;
ObjectAddress tmpAddr;
+ opfstmt.type = T_CreateOpFamilyStmt;
+ opfstmt.opfamilyname = stmt->opclassname;
+ opfstmt.amname = stmt->amname;
+
/*
* Create it ... again no need for more permissions ...
*/
- tmpAddr = CreateOpFamily(stmt->amname, opcname,
+ tmpAddr = CreateOpFamily(&opfstmt, stmt->amname, opcname,
namespaceoid, amoid);
opfamilyoid = tmpAddr.objectId;
}
@@ -792,7 +802,7 @@ DefineOpFamily(CreateOpFamilyStmt *stmt)
errmsg("must be superuser to create an operator family")));
/* Insert pg_opfamily catalog entry */
- return CreateOpFamily(stmt->amname, opfname, namespaceoid, amoid);
+ return CreateOpFamily(stmt, stmt->amname, opfname, namespaceoid, amoid);
}
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 0e7b7b3138..6a5bcded55 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -1721,6 +1721,12 @@ ProcessUtilitySlow(ParseState *pstate,
case T_CreateOpFamilyStmt:
address = DefineOpFamily((CreateOpFamilyStmt *) parsetree);
+
+ /*
+ * DefineOpFamily calls EventTriggerCollectSimpleCommand
+ * directly.
+ */
+ commandCollected = true;
break;
case T_CreateTransformStmt:
diff --git a/src/test/modules/test_ddl_deparse/expected/opfamily.out b/src/test/modules/test_ddl_deparse/expected/opfamily.out
index 14bd6037cd..c7e3a23ef7 100644
--- a/src/test/modules/test_ddl_deparse/expected/opfamily.out
+++ b/src/test/modules/test_ddl_deparse/expected/opfamily.out
@@ -64,4 +64,5 @@ NOTICE: DDL test: type simple, tag CREATE OPERATOR
create operator class ctype_hash_ops
default for type ctype using hash as
operator 1 =(ctype, ctype);
+NOTICE: DDL test: type simple, tag CREATE OPERATOR FAMILY
NOTICE: DDL test: type create operator class, tag CREATE OPERATOR CLASS
diff --git a/src/test/regress/expected/event_trigger.out b/src/test/regress/expected/event_trigger.out
index 44d545de25..8cc70ae3d7 100644
--- a/src/test/regress/expected/event_trigger.out
+++ b/src/test/regress/expected/event_trigger.out
@@ -476,6 +476,11 @@ NOTICE: NORMAL: orig=f normal=t istemp=f type=table identity=evttrig.part_10_15
NOTICE: NORMAL: orig=f normal=t istemp=f type=table identity=evttrig.part_15_20 name={evttrig,part_15_20} args={}
DROP TABLE a_temp_tbl;
NOTICE: NORMAL: orig=t normal=f istemp=t type=table identity=pg_temp.a_temp_tbl name={pg_temp,a_temp_tbl} args={}
+-- CRAETE OPERATOR CLASS without FAMILY clause should report
+-- both CRAETE OPERATOR FAMILY and CRAETE OPERATOR CLASS
+CREATE OPERATOR CLASS evttrigopclass FOR TYPE int USING btree AS STORAGE int;
+NOTICE: END: command_tag=CREATE OPERATOR FAMILY type=operator family identity=public.evttrigopclass USING btree
+NOTICE: END: command_tag=CREATE OPERATOR CLASS type=operator class identity=public.evttrigopclass USING btree
DROP EVENT TRIGGER regress_event_trigger_report_dropped;
DROP EVENT TRIGGER regress_event_trigger_report_end;
-- only allowed from within an event trigger function, should fail
diff --git a/src/test/regress/sql/event_trigger.sql b/src/test/regress/sql/event_trigger.sql
index 1446cf8cc8..8cfc18cb46 100644
--- a/src/test/regress/sql/event_trigger.sql
+++ b/src/test/regress/sql/event_trigger.sql
@@ -337,6 +337,10 @@ DROP INDEX evttrig.one_idx;
DROP SCHEMA evttrig CASCADE;
DROP TABLE a_temp_tbl;
+-- CRAETE OPERATOR CLASS without FAMILY clause should report
+-- both CRAETE OPERATOR FAMILY and CRAETE OPERATOR CLASS
+CREATE OPERATOR CLASS evttrigopclass FOR TYPE int USING btree AS STORAGE int;
+
DROP EVENT TRIGGER regress_event_trigger_report_dropped;
DROP EVENT TRIGGER regress_event_trigger_report_end;
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-19 08:56 Michael Paquier <michael@paquier.xyz>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2022-05-19 08:56 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; pgsql-bugs@lists.postgresql.org
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-20 08:51 Amit Kapila <amit.kapila16@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 13+ messages in thread
From: Amit Kapila @ 2022-05-20 08:51 UTC (permalink / raw)
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>
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.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-20 10:34 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Alvaro Herrera @ 2022-05-20 10:34 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Masahiko Sawada <sawada.mshk@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On 2022-May-20, Amit Kapila wrote:
> On Thu, May 19, 2022 at 2:26 PM Michael Paquier <michael@paquier.xyz> wrote:
> > 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.
+1, like this then.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Attachments:
0001-Fix-CREATE-OPERATOR-CLASS-deparsing.patch (text/x-diff, 0B) download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-20 10:49 Michael Paquier <michael@paquier.xyz>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2022-05-20 10:49 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Masahiko Sawada <sawada.mshk@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Fri, May 20, 2022 at 12:34:32PM +0200, Alvaro Herrera wrote:
> +1, like this then.
That seems fine, at quick glance. Thanks for the patch!
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-20 10:57 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 13+ messages in thread
From: Alvaro Herrera @ 2022-05-20 10:57 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Masahiko Sawada <sawada.mshk@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On 2022-May-20, Michael Paquier wrote:
> That seems fine, at quick glance. Thanks for the patch!
Unfortunately, the tests don't pass in versions 10-13, so I'm
investigating what's up with that.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-20 11:36 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 13+ messages in thread
From: Masahiko Sawada @ 2022-05-20 11:36 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Amit Kapila <amit.kapila16@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Fri, May 20, 2022 at 7:57 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2022-May-20, Michael Paquier wrote:
>
> > That seems fine, at quick glance. Thanks for the patch!
Thank you for updating the patch!
>
> Unfortunately, the tests don't pass in versions 10-13, so I'm
> investigating what's up with that.
I got the failure when testing in 13:
@@ -429,8 +429,6 @@
-- CREATE OPERATOR CLASS without FAMILY clause should report
-- both CREATE OPERATOR FAMILY and CREATE OPERATOR CLASS
CREATE OPERATOR CLASS evttrigopclass FOR TYPE int USING btree AS STORAGE int;
-NOTICE: END: command_tag=CREATE OPERATOR FAMILY type=operator family
identity=public.evttrigopclass USING btree
-NOTICE: END: command_tag=CREATE OPERATOR CLASS type=operator class
identity=public.evttrigopclass USING btree
DROP EVENT TRIGGER regress_event_trigger_report_dropped;
-- only allowed from within an event trigger function, should fail
select pg_event_trigger_table_rewrite_oid();
I think that the event trigger that emits these NOTICE messages
doesn't exist in 13 or older branches. It was added by 2d689babe3c.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-20 14:12 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Alvaro Herrera @ 2022-05-20 14:12 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Amit Kapila <amit.kapila16@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On 2022-May-20, Masahiko Sawada wrote:
> I got the failure when testing in 13:
>
> @@ -429,8 +429,6 @@
> -- CREATE OPERATOR CLASS without FAMILY clause should report
> -- both CREATE OPERATOR FAMILY and CREATE OPERATOR CLASS
> CREATE OPERATOR CLASS evttrigopclass FOR TYPE int USING btree AS STORAGE int;
> -NOTICE: END: command_tag=CREATE OPERATOR FAMILY type=operator family
> identity=public.evttrigopclass USING btree
> -NOTICE: END: command_tag=CREATE OPERATOR CLASS type=operator class
> identity=public.evttrigopclass USING btree
> DROP EVENT TRIGGER regress_event_trigger_report_dropped;
> -- only allowed from within an event trigger function, should fail
> select pg_event_trigger_table_rewrite_oid();
>
> I think that the event trigger that emits these NOTICE messages
> doesn't exist in 13 or older branches. It was added by 2d689babe3c.
Oh, hahah. Hmm, I feel inclined to add the trigger rather than remove
the lines from the expected output.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-20 15:23 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 2 replies; 13+ messages in thread
From: Alvaro Herrera @ 2022-05-20 15:23 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Amit Kapila <amit.kapila16@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On 2022-May-20, Alvaro Herrera wrote:
> On 2022-May-20, Masahiko Sawada wrote:
>
> > I think that the event trigger that emits these NOTICE messages
> > doesn't exist in 13 or older branches. It was added by 2d689babe3c.
>
> Oh, hahah. Hmm, I feel inclined to add the trigger rather than remove
> the lines from the expected output.
So I'm inclined to add the attached patch before the bugfix, in branches
10-13. It simply adds the new event trigger to the existing test case,
being careful not to trip on the error message that it would generate
otherwise, for a bug that was only fixed in 14.
The other option, of course, is to not backpatch any of this earlier
than 14. But the OP says she was experimenting with version 10
initially.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A. Stepanov)
Attachments:
0001-add-regression-tests-by-2d689babe3cb.patch (text/x-diff, 0B) download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-21 03:14 Michael Paquier <michael@paquier.xyz>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 0 replies; 13+ messages in thread
From: Michael Paquier @ 2022-05-21 03:14 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Masahiko Sawada <sawada.mshk@gmail.com>; Amit Kapila <amit.kapila16@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Fri, May 20, 2022 at 05:23:19PM +0200, Alvaro Herrera wrote:
> The other option, of course, is to not backpatch any of this earlier
> than 14. But the OP says she was experimenting with version 10
> initially.
Nah. I think that you are right to have done that down to 10 with the
extra test coming from 14~. Thanks for fixing the issue!
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
@ 2022-05-21 04:27 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 0 replies; 13+ messages in thread
From: Masahiko Sawada @ 2022-05-21 04:27 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Amit Kapila <amit.kapila16@gmail.com>; LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Sat, May 21, 2022 at 12:23 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2022-May-20, Alvaro Herrera wrote:
>
> > On 2022-May-20, Masahiko Sawada wrote:
> >
> > > I think that the event trigger that emits these NOTICE messages
> > > doesn't exist in 13 or older branches. It was added by 2d689babe3c.
> >
> > Oh, hahah. Hmm, I feel inclined to add the trigger rather than remove
> > the lines from the expected output.
>
> So I'm inclined to add the attached patch before the bugfix, in branches
> 10-13. It simply adds the new event trigger to the existing test case,
> being careful not to trip on the error message that it would generate
> otherwise, for a bug that was only fixed in 14.
+1
The patch looks good to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2022-05-21 04:27 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-05-02 11:27 Implicitly created operator family not listed by pg_event_trigger_ddl_commands LEMAIRE Leslie (Chargée de mission) - SG/SNUM/UNI/DRC <leslie.lemaire@developpement-durable.gouv.fr>
2022-05-04 10:17 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-05-06 05:26 ` Masahiko Sawada <sawada.mshk@gmail.com>
2022-05-19 08:56 ` Michael Paquier <michael@paquier.xyz>
2022-05-20 08:51 ` Amit Kapila <amit.kapila16@gmail.com>
2022-05-20 10:34 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-05-20 10:49 ` Michael Paquier <michael@paquier.xyz>
2022-05-20 10:57 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-05-20 11:36 ` Masahiko Sawada <sawada.mshk@gmail.com>
2022-05-20 14:12 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-05-20 15:23 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-05-21 03:14 ` Michael Paquier <michael@paquier.xyz>
2022-05-21 04:27 ` Masahiko Sawada <sawada.mshk@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox