diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2011-06-03 15:38:12 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2011-06-03 15:39:17 -0400 |
commit | ea8e42f3a0848f506d8a1b9c74967248005291cd (patch) | |
tree | 84a5e52e352c425088a47aad847c2eadc944cd7b /src/backend/parser/parse_oper.c | |
parent | 3ece3913d056245d78450793fc5ad18e229a3948 (diff) | |
download | postgresql-ea8e42f3a0848f506d8a1b9c74967248005291cd.tar.gz postgresql-ea8e42f3a0848f506d8a1b9c74967248005291cd.zip |
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.
Diffstat (limited to 'src/backend/parser/parse_oper.c')
-rw-r--r-- | src/backend/parser/parse_oper.c | 36 |
1 files changed, 0 insertions, 36 deletions
diff --git a/src/backend/parser/parse_oper.c b/src/backend/parser/parse_oper.c index 15a3bb3a013..4a2f77771b8 100644 --- a/src/backend/parser/parse_oper.c +++ b/src/backend/parser/parse_oper.c @@ -211,42 +211,6 @@ get_sort_group_operators(Oid argtype, gt_opr = typentry->gt_opr; hashable = OidIsValid(typentry->hash_proc); - /* - * If the datatype is an array, then we can use array_lt and friends ... - * but only if there are suitable operators for the element type. - * Likewise, array types are only hashable if the element type is. Testing - * all three operator IDs here should be redundant, but let's do it - * anyway. - */ - if (lt_opr == ARRAY_LT_OP || - eq_opr == ARRAY_EQ_OP || - gt_opr == ARRAY_GT_OP) - { - Oid elem_type = get_base_element_type(argtype); - - if (OidIsValid(elem_type)) - { - typentry = lookup_type_cache(elem_type, cache_flags); - if (!OidIsValid(typentry->eq_opr)) - { - /* element type is neither sortable nor hashable */ - lt_opr = eq_opr = gt_opr = InvalidOid; - } - else if (!OidIsValid(typentry->lt_opr) || - !OidIsValid(typentry->gt_opr)) - { - /* element type is hashable but not sortable */ - lt_opr = gt_opr = InvalidOid; - } - hashable = OidIsValid(typentry->hash_proc); - } - else - { - lt_opr = eq_opr = gt_opr = InvalidOid; /* bogus array type? */ - hashable = false; - } - } - /* Report errors if needed */ if ((needLT && !OidIsValid(lt_opr)) || (needGT && !OidIsValid(gt_opr))) |