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
