On Mon, Aug 31, 2026 at 1:42 AM Andrey Borodin <[email protected]> wrote:
>
> Hi Jian,
>
> While revisiting v11, I realized that I had missed one design question
> in my earlier review.
>
> Since CREATE_TABLE_LIKE_ALL includes every option bit, adding
> CREATE_TABLE_LIKE_TRIGGERS means that existing statements such as
>
> CREATE TABLE staging (LIKE production INCLUDING ALL);
>
> will start copying user triggers after a major-version upgrade. This
> may cause a staging or replacement table to execute audit or other
> application logic that it did not execute before.
>
> Is this change in the meaning of INCLUDING ALL intended, or should
> triggers require an explicit INCLUDING TRIGGERS? There may already be
> an established rule or an earlier conclusion about adding new LIKE
> options to INCLUDING ALL that I have missed.
>
Refer to the gram.y;
TableLikeOptionList:
TableLikeOptionList INCLUDING TableLikeOption { $$ = $1 | $3; }
| TableLikeOptionList EXCLUDING TableLikeOption { $$ = $1 & ~$3; }
| /* EMPTY */ { $$ = 0; }
;
typedef enum TableLikeOption
{
....
CREATE_TABLE_LIKE_ALL = PG_INT32_MAX
} TableLikeOption;
If ($3 == PG_INT32_MAX), OR-ing it with any other option bits ($1 |
$3) always yields PG_INT32_MAX.
In other words, INCLUDING ALL sets every option bit, so it necessarily
includes triggers as well.
I think this is an established rule.
--
jian
https://www.enterprisedb.com/
