Re: Hashed SAOP on composite type with non-hashable column errors at runtime

Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> There is an issue when we use a record-based array operation in SQL:

> EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, BUFFERS OFF, SUMMARY OFF)
> SELECT count(*) FROM test
> WHERE (a,b) = ANY (ARRAY[
> (1, 'w1'::tsvector), (2, 'w2'::tsvector), (3, 'w3'::tsvector),
> (4, 'w4'::tsvector), (5, 'w5'::tsvector), (6, 'w6'::tsvector),
> (7, 'w7'::tsvector), (8, 'w8'::tsvector), (9, 'w9'::tsvector)
> ]);
> ERROR: could not identify a hash function for type tsvector

Yeah, this is a bug, but I don't think you've identified the
full scope of the problem. In the first place, there's another
get_op_hash_functions call in selfuncs.c that's also at risk.
In the second place, the same hazard exists for range and
multirange types, which can have non-hashable subtypes.
AFAICT noplace at all is defending against that.

So I'm unexcited about putting the fix for this into
convert_saop_to_hashed_saop_walker as you've done here.
I think it needs to be addressed at the level of the relevant
lsyscache.c lookup functions, so that there's some chance that
future code additions will get this right. Draft fix attached.

I can't get excited about the test case you suggest;
it's rather expensive and it will do nothing whatever
to guard against future mistakes of the same kind.

I'm also unexcited about your 0002 and 0003. I don't really
care about optimizing the anonymous-record case; by and large,
it's coincidental that complicated operations work at all on
anonymous record types.

regards, tom lane