> > Shouldn't this preserve the enabled state of the triggers, or if it
> > doesn't, should the documentation include this limitations?
> >
>
> I intended to document it as ...
After looking into this a bit more, I am more on the side of copying
this setting properly.
The already existing INCLUDING CONSTRAINTS copies the constraints,
including their enabled/disabled status, correctly marking them
disabled if a CHECK constraint is defined but not enforced. Wouldn't
it be strange for INCLUDING TRIGGERS to work differently?
From the test suite:
CREATE TABLE ctlt1_inh (LIKE ctlt1 INCLUDING CONSTRAINTS INCLUDING
COMMENTS) INHERITS (ctlt1);
\d+ ctlt1_inh
Table "public.ctlt1_inh"
Column | Type | Collation | Nullable | Default | Storage | Stats
target | Description
--------+------+-----------+----------+---------+----------+--------------+-------------
a | text | | not null | | main | | A
b | text | | | | extended | | B
Check constraints:
"cc" CHECK (length(b) > 100)
"ctlt1_a_check" CHECK (length(a) > 2)
"ctlt1_b_check" CHECK (length(b) > 100) NOT ENFORCED
Not-null constraints:
"ctlt1_a_not_null" NOT NULL "a" (local, inherited)
Inherits: ctlt1
