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

From Peter Geoghegan
Subject Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Date
Msg-id CAM3SWZQjm8DH=ewsQtKS5-LQHcMJ_=cFFC8Syhd9DaXBnvLFpQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Jun 27, 2016 at 7:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Meh.  I do not really think that dromedary's test options
> (-DCOPY_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST) represent a model
> to follow for this problem.  In both of those cases, the value of having
> the option turned on is that it will exercise code that hasn't even been
> written yet.  So those options have to be enabled across the entire test
> suite in order to be of much use.  Furthermore, there's no particular
> reason to think that they'd expose platform-dependent behavior, so there's
> no real downside to having just one or two buildfarm critters using them.

You think that the hash index tuplesort code should be possible to
exercise in the regression tests dynamically, without any new #define
whatsoever. Fair enough, but I still think that enabling debug #define
options should be possible at a coarser granularity, even if that ends
up covering a set of cases that are not very crisply defined. Maybe
that's a discussion for the next time something like
RAW_EXPRESSION_COVERAGE_TEST is proposed, though.

--
Peter Geoghegan

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column