| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | assam258(at)gmail(dot)com, zsolt(dot)parragi(at)percona(dot)com, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CREATE TABLE LIKE INCLUDING TRIGGERS |
| Date: | 2026-08-30 17:42:44 |
| Message-ID: | 9F16DBBF-C805-433F-8D3C-3663D70190C1@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 8, 2026 at 1:05 PM jian he
<jian(dot)universality(at)gmail(dot)com> wrote:
> I also combined two patches (v10-0001, v10-0002) into one
> (v11-0001).
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.
Thank you!
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2026-08-30 17:46:07 | Re: GIN pageinspect support for entry tree and posting tree |
| Previous Message | Andrey Borodin | 2026-08-30 17:35:14 | Re: pg_rewind does not rewind diverging timelines |