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
