]> granicus.if.org Git - postgresql/commit
Fix assorted bugs in pg_get_partition_constraintdef().
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Sep 2018 22:15:06 +0000 (18:15 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Sep 2018 22:15:17 +0000 (18:15 -0400)
commitaaf10f32a308bc5f53772c773edf3f345f59bb74
tree87b71d038df8d0ea9fde924d8992758804320551
parent4ec90f53f10141867d8b86f58d72990a13ff267b
Fix assorted bugs in pg_get_partition_constraintdef().

It failed if passed a nonexistent relation OID, or one that was a non-heap
relation, because of blindly applying heap_open to a user-supplied OID.
This is not OK behavior for a SQL-exposed function; we have a project
policy that we should return NULL in such cases.  Moreover, since
pg_get_partition_constraintdef ought now to work on indexes, restricting
it to heaps is flat wrong anyway.

The underlying function generate_partition_qual() wasn't on board with
indexes having partition quals either, nor for that matter with rels
having relispartition set but yet null relpartbound.  (One wonders
whether the person who wrote the function comment blocks claiming that
these functions allow a missing relpartbound had ever tested it.)

Fix by testing relispartition before opening the rel, and by using
relation_open not heap_open.  (If any other relkinds ever grow the
ability to have relispartition set, the code will work with them
automatically.)  Also, don't reject null relpartbound in
generate_partition_qual.

Back-patch to v11, and all but the null-relpartbound change to v10.
(It's not really necessary to change generate_partition_qual at all
in v10, but I thought s/heap_open/relation_open/ would be a good
idea anyway just to keep the code in sync with later branches.)

Per report from Justin Pryzby.

Discussion: https://postgr.es/m/20180927200020.GJ776@telsasoft.com
src/backend/utils/cache/lsyscache.c
src/backend/utils/cache/partcache.c
src/include/utils/lsyscache.h
src/test/regress/expected/indexing.out
src/test/regress/sql/indexing.sql