aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/jsonpath.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-03-11 13:47:26 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2022-03-11 13:47:29 -0500
commit641f3dffcdf1c7378cfb94c98b6642793181d6db (patch)
tree85814d22f872c957113f870e4382a150cc0f65b9 /src/backend/utils/adt/jsonpath.c
parentd6f1cdeb9a9ea227f87a2156e3a1ed94706b2193 (diff)
downloadpostgresql-641f3dffcdf1c7378cfb94c98b6642793181d6db.tar.gz
postgresql-641f3dffcdf1c7378cfb94c98b6642793181d6db.zip
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
Diffstat (limited to 'src/backend/utils/adt/jsonpath.c')
0 files changed, 0 insertions, 0 deletions