OSDN Git Service

Fix failure to check whether a rowtype's component types are sortable.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 3 Jun 2011 19:38:12 +0000 (15:38 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 3 Jun 2011 19:39:17 +0000 (15:39 -0400)
commitea8e42f3a0848f506d8a1b9c74967248005291cd
tree84a5e52e352c425088a47aad847c2eadc944cd7b
parent3ece3913d056245d78450793fc5ad18e229a3948
Fix failure to check whether a rowtype's component types are sortable.

The existence of a btree opclass accepting composite types caused us to
assume that every composite type is sortable.  This isn't true of course;
we need to check if the column types are all sortable.  There was logic
for this for the case of array comparison (ie, check that the element
type is sortable), but we missed the point for rowtypes.  Per Teodor's
report of an ANALYZE failure for an unsortable composite type.

Rather than just add some more ad-hoc logic for this, I moved knowledge of
the issue into typcache.c.  The typcache will now only report out array_eq,
record_cmp, and friends as usable operators if the array or composite type
will work with those functions.

Unfortunately we don't have enough info to do this for anonymous RECORD
types; in that case, just assume it will work, and take the runtime failure
as before if it doesn't.

This patch might be a candidate for back-patching at some point, but
given the lack of complaints from the field, I'd rather just test it in
HEAD for now.

Note: most of the places touched in this patch will need further work
when we get around to supporting hashing of record types.
src/backend/optimizer/plan/subselect.c
src/backend/parser/parse_oper.c
src/backend/utils/cache/lsyscache.c
src/backend/utils/cache/typcache.c
src/include/catalog/pg_operator.h
src/include/utils/typcache.h
src/test/regress/expected/rowtypes.out
src/test/regress/sql/rowtypes.sql