2017-11-14 18:42 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
> Robert is correct that putting this into the parser is completely the
> wrong thing. If you do that, then for example views using the features
> will reverse-list in the rewritten form, which we Do Not Want, even
> if the rewritten form is completely valid SQL (is it?).
Yes, the subnode to our executor is rewritten in valid SQL.
> You might consider putting the rewriting into, um, the rewriter.
> It could be a separate pass after view expansion, if direct integration
> with the existing behavior seems unduly spaghetti-ish. Or do it in
> an early phase of planning as he suggested. There's not really that
> much difference between the rewriter and the planner for this purpose.
> Although one way to draw the distinction is that the output of the
> rewriter is (currently) still fully expressible as plain SQL, whereas
> once the planner goes into action the intermediate states of the tree
> might not really be SQL anymore (eg, it might contain join types that
> don't correspond to any SQL syntax). So depending on what your rewrite
> emits, there would be a weak preference for calling it part of the
> rewriter or planner respectively.
Thank you for your feedback. We'll have a look at this and come back to you.