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

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.

In response to

Responses

Browse pgsql-hackers by date

  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