From: | Peter Moser <peter(dot)moser(at)unibz(dot)it> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] [PROPOSAL] Temporal query processing with range types |
Date: | 2017-11-16 08:32:09 |
Message-ID: | CAHO0eLYzy3U2dTdANsbx-tGruEE3QX+mjOmWBR2ExfWdKe_Xwg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-11-14 18:42 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Golub | 2017-11-16 08:52:45 | ./configure fails for --host=i686-w64-mingw32 on Ubuntu |
Previous Message | Masahiko Sawada | 2017-11-16 08:30:02 | Re: User defined data types in Logical Replication |