| From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | amul sul <sulamul(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 64-bit hash function for hstore and citext data type |
| Date: | 2018-11-22 20:29:34 |
| Message-ID: | 87d0qwsw4a.fsf@news-spur.riddles.org.uk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>>>> "Tomas" == Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
Tomas> I wonder if the hstore hash function is actually correct. I see
Tomas> it pretty much just computes hash on the varlena representation.
Tomas> The important question is - can there be two different encodings
Tomas> for the same hstore value?
I was going to say "no", but in fact on closer examination there is an
edge case caused by the fact that hstoreUpgrade allows an _empty_ hstore
from pg_upgraded 8.4 data through without modifying it. (There's also a
vanishingly unlikely case involving the pgfoundry release of hstore-new.)
I'm inclined to fix this in hstoreUpgrade rather than complicate
hstore_hash with historical trivia. Also there have been no field
complaints - I guess it's unlikely that there is much pg 8.4 hstore data
in the wild that anyone wants to hash.
--
Andrew (irc:RhodiumToad)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2018-11-22 20:37:23 | Re: pg_upgrade supported versions policy |
| Previous Message | Nikolay Shaplov | 2018-11-22 19:01:26 | Re: Add extension options to control TAP and isolation tests |