On Wed, Aug 16, 2017 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> After some further thought, I propose the following approach to the >> issues raised on this thread: > >> 1. Allow hash functions to have a second, optional support function, >> similar to what we did for btree opclasses in >> c6e3ac11b60ac4a8942ab964252d51c1c0bd8845. The second function will >> have a signature of (opclass_datatype, int64) and should return int64. >> The int64 argument is a salt. When the salt is 0, the low 32 bits of >> the return value should match what the existing hash support function >> returns. Otherwise, the salt should be used to perturb the hash >> calculation. > > +1
Attached is a quick sketch of how this could perhaps be done (ignoring for the moment the relatively-boring opclass pushups). It introduces a new function hash_any_extended which differs from hash_any() in that (a) it combines both b and c into the result and (b) it accepts a seed which is mixed into the initial state if it's non-zero. Comments? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
hash-any-extended-v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
