]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Restore the previous semantics of get_constraint_index().
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 11 Mar 2022 18:47:26 +0000 (13:47 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 11 Mar 2022 18:47:26 +0000 (13:47 -0500)
commit8dcd1c3564f04bc1f71020c150b31deea07b7a95
tree5539770a0a15e3b9d1b5d77f294de2fd54d79bd4
parent8f091572873c072ff844b0e2e18088ec51e4b03f
Restore the previous semantics of get_constraint_index().

Commit 8b069ef5d changed this function to look at pg_constraint.conindid
rather than searching pg_depend.  That was a good performance improvement,
but it failed to preserve the exact semantics.  The old code would only
return an index that was "owned by" (internally dependent on) the
specified constraint, whereas the new code will also return indexes that
are just referenced by foreign key constraints.  This confuses ALTER
TABLE, which was implicitly expecting the previous semantics, into
failing with errors like
    ERROR:  relation 146621 has multiple clustered indexes
or
    ERROR:  "pk_attbl" is not an index for table "atref"

We can fix this without reverting the performance improvement by adding
a contype check in get_constraint_index().  Another way could be to
make ALTER TABLE check it, but I'm worried that extension code could
also have subtle dependencies on the old semantics.

Tom Lane and Japin Li, per bug #17409 from Holly Roberts.
Back-patch to v14 where the error crept in.

Discussion: https://postgr.es/m/17409-52871dda8b5741cb@postgresql.org
src/backend/utils/cache/lsyscache.c
src/test/regress/expected/alter_table.out
src/test/regress/sql/alter_table.sql