]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 19 Nov 2020 20:03:17 +0000 (15:03 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 19 Nov 2020 20:03:17 +0000 (15:03 -0500)
commit513db7b7004c8d1fa15dea4747a32cbc8f9621ef
treec0fae246e4086e9f25baae667069d13ba5a02419
parent214f22823f2033330853d35740fddea315f88b64
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs.

Commit 502898192 was too careless about the order of execution of the
additional ALTER TABLE operations generated by expandTableLikeClause.
It just stuck them all at the end, which seems okay for most purposes.
But it falls down in the case where LIKE is importing a primary key
or unique index and the outer CREATE TABLE includes a FOREIGN KEY
constraint that needs to depend on that index.  Weird as that is,
it used to work, so we ought to keep it working.

To fix, make parse_utilcmd.c insert LIKE clauses between index-creation
and FK-creation commands in the transformed list of commands, and change
utility.c so that the commands generated by expandTableLikeClause are
executed immediately not at the end.  One could imagine scenarios where
this wouldn't work either; but currently expandTableLikeClause only
makes column default expressions, CHECK constraints, and indexes, and
this ordering seems fine for those.

Per bug #16730 from Sofoklis Papasofokli.  Like the previous patch,
back-patch to all supported branches.

Discussion: https://postgr.es/m/16730-b902f7e6e0276b30@postgresql.org
src/backend/parser/parse_utilcmd.c
src/backend/tcop/utility.c
src/test/regress/expected/create_table_like.out
src/test/regress/sql/create_table_like.sql