Re: Hash support for row types

Hi,

On 2020-10-19 10:01:14 +0200, Peter Eisentraut wrote:
> In [0] it was discussed that hash support for row types/record would be
> handy.  So I implemented that.

> The implementation hashes each field and combines the hash values.  Most of
> the code structure can be borrowed from the record comparison
> functions/btree support.  To combine the hash values, I adapted the code
> from the array hashing functions.  (The hash_combine()/hash_combine64()
> functions also looked sensible, but they don't appear to work in a way that
> satisfies the hash_func regression test.  Could be documented better.)
> 
> The main motivation is to support UNION [DISTINCT] as discussed in [0], but
> this also enables other hash-related functionality such as hash joins (as
> one regression test accidentally revealed) and hash partitioning.

How does this deal with row types with a field that doesn't have a hash
function? Erroring out at runtime could cause queries that used to
succeed, e.g. because all fields have btree ops, to fail, if we just have
a generic unconditionally present hash opclass?  Is that an OK
"regression"?

Greetings,

Andres Freund