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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Дата
Msg-id CAM3SWZQjm8DH=ewsQtKS5-LQHcMJ_=cFFC8Syhd9DaXBnvLFpQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column