Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

Peter Moser <peter(dot)moser(at)unibz(dot)it> writes:
> 2017-11-11 13:19 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> Overall, I think that the whole approach here probably needs to be
>> scrapped and rethought. The stuff this patch is doing really belongs
>> in the optimizer, not the parser, I think. It could possibly happen
>> at a relatively early stage in the optimizer so that the rest of the
>> optimizer can see the results of the transformation and, well,
>> optimize. But parse time is way too early.

> We create this query rewrites during parser stage, because we want
> that the optimizer chooses the best strategies for each rewritten
> subplan and that our executor nodes get the desired input format in
> the most optimal way. Our goal was an integration that re-uses the
> existing PostgreSQL rewrites and optimizations fully.

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?).

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.

regards, tom lane