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 по дате отправления: