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-16 21:57:07
Message-ID: 202107162157.53swi4o7wo2q@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I noticed that in pg_dump --clean, we were still emitting DROP lines for
the triggers in the partitions, which raises errors; so I emptied that
too.

On 2021-Jul-14, Alvaro Herrera wrote:

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

Actually, that is wrong; unlike is there just to be able to subtract
dumps from the set that is going to be searched for the regexp, for when
you want to use one of the hashes (%full_runs) but ignore a few of
those.

> I have fixed that here, and verified that the tests are doing what we
> wanted them to do.

... and I added some more tests, for pg_upgrade.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La espina, desde que nace, ya pincha" (Proverbio africano)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-07-16 22:01:12 Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers
Previous Message Alvaro Herrera 2021-07-16 21:35:33 Re: row filtering for logical replication