Re: BUG #13891: Deparsed arbiter WHERE clauses cannot be parsed by Postgres
От | Tom Lane |
---|---|
Тема | Re: BUG #13891: Deparsed arbiter WHERE clauses cannot be parsed by Postgres |
Дата | |
Msg-id | 22766.1454875331@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #13891: Deparsed arbiter WHERE clauses cannot be parsed by Postgres (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #13891: Deparsed arbiter WHERE clauses cannot be parsed by Postgres
|
Список | pgsql-bugs |
Andres Freund <andres@anarazel.de> writes: > On 2016-02-04 13:09:43 -0800, Peter Geoghegan wrote: >> Sorry, I still don't get it. How does that help with ON CONFLICT >> arbiter WHERE clause deparsing? > The bug this thread is about was actually visible in regression test > output, as the wrong output of pg_rules output. As were a number of > previous bugs. So it seems time to actually make sure that the output of > the rules we generate to test deparsing actually do something remotely > sane, by executing the deparsed sql. Obviously human inspection is not > sufficient. You can do so by executing deparsed output of a rule or a > view (both should be doable afacis). That's all very well, but we have a release to get out tomorrow, so I went ahead and pushed Peter's patch (with some cosmetic fiddling). I think actually Andres' proposal wouldn't be all that helpful, because it would only detect deparse problems for constructs that happen to appear in views/rules that exist at the instant the test runs. What I'd be inclined to think about is something comparable to the COPY_PARSE_PLAN_TREES #define, that is an option to make postgres.c pass every non-utility statement through deparse and reparse and then compare the resulting parse trees. It'd be a bit slow but it would cover every type of syntax exercised anywhere in the regression tests. regards, tom lane
В списке pgsql-bugs по дате отправления: