On Wed, Aug 16, 2017 at 12:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers