Re: Proposing WITH ITERATIVE

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposing WITH ITERATIVE
Date: 2020-04-30 15:58:09
Message-ID: 2d6ac118a6d602a2a0b6cbe4f75bd54154cab26e.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2020-04-28 at 11:57 -0400, Jonah H. Harris wrote:
> Yeah, in that specific case, one of the other implementations seems
> to carry the counters along in the executor itself. But, as not all
> uses of this functionality are iteration-count-based, I think that's
> a little limiting. Using a terminator expression (of some kind) seems
> most adaptable, I think. I'll give some examples of both types of
> cases.

In my experience, graph algorithms or other queries doing more
specialized analysis tend to get pretty complex with lots of special
cases. Users may want to express these algorithms in a more familiar
language (R, Python, etc.), and to version the code (probably in an
extension).

Have you considered taking this to the extreme and implementing
something like User-Defined Table Operators[1]? Or is there a
motivation for writing such algorithms inline in SQL?

Regards,
Jeff Davis

[1] http://www.vldb.org/conf/1999/P47.pdf

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-04-30 18:02:59 Re: SLRU statistics
Previous Message Fujii Masao 2020-04-30 15:25:46 Re: Why are wait events not reported even though it reads/writes a timeline history file?