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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] [PROPOSAL] Temporal query processing with range types
Дата
Msg-id CANP8+jKjj3EqRUhxpx_WfAfnO2X6w+wp0dfkqeLmomKkNfbSkA@mail.gmail.com
обсуждение исходный текст
Ответ на [PROPOSAL] Temporal query processing with range types  (Anton Dignös <dignoes@inf.unibz.it>)
Ответы Re: [HACKERS] [PROPOSAL] Temporal query processing with range types  (Peter Moser <pitiz29a@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Automatic testing of patches in commit fest