Re: Proposing WITH ITERATIVE

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: Proposing WITH ITERATIVE
Дата
Msg-id CADkLM=eHfrqqjfii9kEHn=zDHQpZXM25BcvyoqSasR8bVS65iQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposing WITH ITERATIVE  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Ответы Re: Proposing WITH ITERATIVE
Список pgsql-hackers
On Wed, Apr 29, 2020 at 10:34 AM Jonah H. Harris <jonah.harris@gmail.com> wrote:
On Wed, Apr 29, 2020 at 7:22 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
Yeah the RECURSIVE vs ITERATIVE is a bit of a red herring here.  As you
say, the RECURSIVE keyword doesn't specify the processing but marks the
fact that the specification of the query is recursive.

Agreed. I started thinking through Fabien's response last night.

I think a syntax that would fit better within the existing framework
would be something like

WITH RECURSIVE t AS (
     SELECT base case
   REPLACE ALL  -- instead of UNION ALL
     SELECT recursive case
)

I was originally thinking more along the lines of Fabien's approach, but this is similarly interesting.

Obviously I'm very concerned about doing something that the SQL Standard will clobber somewhere down the road. Having said that, the recursive syntax always struck me as awkward even by SQL standards.

Perhaps something like this would be more readable

WITH t AS (
    UPDATE ( SELECT 1 AS ctr, 'x' as val )
    SET ctr = ctr + 1, val = val || 'x'
    WHILE ctr <= 100
    RETURNING ctr, val
)

The notion of an UPDATE on an ephemeral subquery isn't that special, see "subquery2" in  https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/update_statement.htm , so the only syntax here without precedence is dropping a WHILE into an UPDATE statement. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vinicius Abrahao
Дата:
Сообщение: SEQUENCE values (duplicated) in some corner cases when crash happens
Следующее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: PG compilation error with Visual Studio 2015/2017/2019