Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Amit Langote <amitlangote09(at)gmail(dot)com>
Subject: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers
Date: 2021-07-14 23:45:23
Message-ID: 202107142345.2mdefvxfzhjy@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Looking over the tests added by your (Justin's) patch, there was a
problem checking for non-existance of the CREATE TRIGGER line: it
doesn't work to use "like => {}" (empty), you need to use
"unlike => { everything }". So your test was not catching the fact that
we were, in fact, emitting the undesirable line. I have fixed that
here, and verified that the tests are doing what we wanted them to do.

I also verified the new test in 0001. I was about to add a test for the
legacy inheritance case, but I eventually realized that it was already
being tested by the lines I added in commit bbb927b4db9b.

I have one vote for backpatching 0001 to pg11. Any others? To be
clear: the issue is that if a partitioned table has a disabled trigger,
and a partition is created, the trigger is created as enabled in the
partition. With this patch, the trigger would be created as disabled.
Do people think that that behavior change would be unwelcome?

--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte"
(Ijon Tichy en Viajes, Stanislaw Lem)

Attachment Content-Type Size
v4-0001-Preserve-firing-on-state-when-cloning-row-trigger.patch text/x-diff 9.9 KB
v4-0002-Fix-pg_dump-for-triggers-with-changed-enabled-fla.patch text/x-diff 8.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2021-07-15 00:10:18 Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Previous Message David Rowley 2021-07-14 23:43:20 Re: [PATCH] Use optimized single-datum tuplesort in ExecSort