From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Daniel Newman <dtnewman(at)gmail(dot)com>, danielnewman(at)umich(dot)edu, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Date: | 2016-06-24 20:04:22 |
Message-ID: | 9335.1466798662@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jun 23, 2016 at 7:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We can either revert the aforesaid commit so far as it affects hash,
>> or do something to break _hash_form_tuple's encapsulation of the
>> hash-value-for-data substitution. I don't immediately see a non-messy
>> way to do the latter.
> Would it work to have something like _hash_form_tuple() except that
> instead of returning an index tuple it would just return the Datum and
> isnull flags and let the caller decide what to do with them?
Yeah. Let's define it as a function that transforms input values/isnull
arrays into output values/isnull arrays. It seems all right for the
callers to know the latter are always of length 1, so they can be local
variables in the callers. I'll go make it so.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-06-24 21:04:52 | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Previous Message | Robert Haas | 2016-06-24 17:57:51 | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |