Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column

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

In response to

Browse pgsql-bugs by date

  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