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 22:01:12
Message-ID: 202107162201.g243c7mnnxuy@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Jul-16, Justin Pryzby wrote:

> CREATE TABLE p(i int) PARTITION BY RANGE(i);
> CREATE TABLE p1 PARTITION OF p FOR VALUES FROM (1)TO(2);
> CREATE FUNCTION foo() returns trigger LANGUAGE plpgsql AS $$begin end$$;
> CREATE TRIGGER x AFTER DELETE ON p1 EXECUTE FUNCTION foo();
> CREATE TRIGGER x AFTER DELETE ON p EXECUTE FUNCTION foo();

Hmm, interesting -- those statement triggers are not cloned, so what is
going on here is just that the psql query to show them is tripping on
its shoelaces ... I'll try to find a fix.

I *think* the problem is that the query matches triggers by name and
parent/child relationship; we're missing to ignore triggers by tgtype.
It's not great design that tgtype is a bitmask of unrelated flags ...

--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-07-16 23:13:03 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Previous Message Alvaro Herrera 2021-07-16 21:57:07 Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers