Re: [HACKERS] [PROPOSAL] Temporal query processing with range types - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] [PROPOSAL] Temporal query processing with range types
Date
Msg-id CANP8+jKjj3EqRUhxpx_WfAfnO2X6w+wp0dfkqeLmomKkNfbSkA@mail.gmail.com
Whole thread Raw
In response to [PROPOSAL] Temporal query processing with range types  (Anton Dignös <dignoes@inf.unibz.it>)
Responses Re: [HACKERS] [PROPOSAL] Temporal query processing with range types
List pgsql-hackers
On 30 March 2017 at 13:11, Peter Moser <pitiz29a@gmail.com> wrote:
> 2017-03-01 10:56 GMT+01:00 Peter Moser <pitiz29a@gmail.com>:
>> A similar walkthrough for ALIGN will follow soon.
>>
>> We are thankful for any suggestion or ideas, to be used to write a
>> good SGML documentation.
>
> The attached README explains the ALIGN operation step-by-step with a
> TEMPORAL LEFT OUTER JOIN example. That is, we start from a query
> input, show how we rewrite it during parser stage, and show how the
> final execution generates result tuples.

Thanks for this contribution. I know what it takes to do significant
contributions and I know it can be frustrating when things languish
for months.

I am starting to look at temporal queries myself so I will begin an interest.

PostgreSQL tries really very hard to implement the SQL Standard and
just the standard. ISTM that the feedback you should have been given
is that this is very interesting but will not be committed in its
current form; I am surprised to see nobody has said that, though you
can see the truth of that since nobody is actively looking to review
or commit this. Obviously if the standard were changed to support
these things we'd suddenly be interested...

What I think I'm lacking is a clear statement of why we need to have
new syntax to solve the problem and why the problem itself is
important.

PostgreSQL supports the ability to produce Set Returning Functions and
various other extensions. Would it be possible to change this so that
we don't add new syntax to the parser but rather we do this as a set
of functions?

An alternative might be for us to implement a pluggable parser, so
that you can have an "alternate syntax" plugin. If we did that, you
can then maintain the plugin outside of core until the time when SQL
Standard is updated and we can implement directly. We already support
the ability to invent new plan nodes, so this could be considered as
part of the plugin.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Setting pd_lower in GIN metapage
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Automatic testing of patches in commit fest