2017-11-14 18:42 GMT+01:00 Tom Lane <t...@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.