From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <stark(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Saner interval hash function |
Date: | 2009-04-04 15:16:24 |
Message-ID: | 18770.1238858184@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <stark(at)enterprisedb(dot)com> writes:
> On Fri, Apr 3, 2009 at 10:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The present implementation of interval_hash() is very carefully designed
>> and coded ... to meet the wrong specification :-(. What it should
>> be doing is producing equal hashcodes for values that interval_eq()
>> considers equal. The error is exhibited in the recent bug report #4748.
> It would be nice if we had a way to generate a lot of similar values
> for a every data type. Then we could have a regression test which
> checks for each data type that the hash function matches the equality
> operator -- and for that matter that the various inequality operators
> are also consistent.
> I'm not sure how to generate values though. For a lot of data types it
> would be hard to generate values densely enough to trigger any bugs.
Yeah. I did add a regression test for the specific case of '30 days'
vs '1 month', which we know is a pain point for this particular data
type. Generating values at random doesn't seem like it's really likely
to teach us much though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-04-04 15:42:59 | Re: Saner interval hash function |
Previous Message | Tom Lane | 2009-04-04 15:10:07 | Re: GetCurrentVirtualXIDs() |