]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Reject system columns as elements of foreign keys.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 31 Mar 2023 15:18:49 +0000 (11:18 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 31 Mar 2023 15:18:49 +0000 (11:18 -0400)
commite8d74aac522a41e605d8f19fa1947fb118d43011
tree8ee44c9f2420b451183fc4841ef2942839aa9c4c
parentd0d92fe3d49934042f64539ccf2bb33c5f82158a
Reject system columns as elements of foreign keys.

Up through v11 it was sensible to use the "oid" system column as
a foreign key column, but since that was removed there's no visible
usefulness in making any of the remaining system columns a foreign
key.  Moreover, since the TupleTableSlot rewrites in v12, such cases
actively fail because of implicit assumptions that only user columns
appear in foreign keys.  The lack of complaints about that seems
like good evidence that no one is trying to do it.  Hence, rather
than trying to repair those assumptions (of which there are at least
two, maybe more), let's just forbid the case up front.

Per this patch, a system column in either the referenced or
referencing side of a foreign key will draw this error; however,
putting one in the referenced side would have failed later anyway,
since we don't allow unique indexes to be made on system columns.

Per bug #17877 from Alexander Lakhin.  Back-patch to v12; the
case still appears to work in v11, so we shouldn't break it there.

Discussion: https://postgr.es/m/17877-4bcc658e33df6de1@postgresql.org
src/backend/commands/tablecmds.c
src/test/regress/expected/foreign_key.out
src/test/regress/sql/foreign_key.sql