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
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? |