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

Peter Geoghegan <pg@heroku.com> writes:
> On Sat, Jun 25, 2016 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't exactly see how that leads to any improvement --- you still end
>> up having to manually configure some buildfarm critters for coverage, no?

> Yes, but you only have to do it once. I don't see the problem with
> creating a #define that represents a grab-bag of debug options that
> should run on one or two buildfarm animals. That doesn't preclude also
> allowing things like RAW_EXPRESSION_COVERAGE_TEST to be enabled more
> selectively.

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.

But exercising a non-default code path in hash index build is something we
only need in one place in the tests, and at least in my judgment there is
a possibility for platform-specific behavior.  So I think some way of
turning it on dynamically, and then adding that as a standard test case,
would be a considerable improvement.  I just don't quite want to go to the
effort of inventing a GUC or reloption.  Is there some intermediate
answer?

            regards, tom lane