Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers
Date
Msg-id 20201016135230.GA23633@alvherre.pgsql
Whole thread Raw
In response to CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 2020-Sep-30, Justin Pryzby wrote:

> postgres=# SELECT tgrelid::regclass, tgenabled FROM pg_trigger WHERE tgrelid::regclass::text IN ('t1','t2');
>  tgrelid | tgenabled 
> ---------+-----------
>  t1      | D
>  t2      | O
> (2 rows)
> 
> I consider this a bug,

Yeah.

> but CreateTrigStmt doesn't have any "enabled" member
> (since it's impossible to CREATE TRIGGER .. DISABLED), so I'm not sure where
> the fix should be.

I suggest we add a new function, as in the attached.  It's important to
keep the ABI of CreateTrigger unchanged, for the sake of
backpatchability, but ISTM it's equally important to keep its API
unchanged, because outside callers such as ProcessUtility_slow does not
have to care about the new trigger's enabled state.

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: partition routing layering in nodeModifyTable.c
Next
From: Alvaro Herrera
Date:
Subject: Re: Improper use about DatumGetInt32