I wrote:
> ... I'd love to
> toss the entire SRF-in-tlist feature overboard one of these years,
> both because of semantic issues like these and because a fair amount
> of code and overhead could be ripped out if it were disallowed.
> But I don't know how we get to that --- as Merlin says, there's a
> pretty large amount of application code depending on the feature.
BTW, after further thought I seem to recall some discussion about whether
we could mechanically transform SRF-in-tlist into a LATERAL query.
That is, we could make the rewriter or planner convert
SELECT srf1(...), srf2(...) FROM ... WHERE ...
into
SELECT u.s1, u.s2 FROM ..., LATERAL ROWS FROM(srf1(...), srf2(...)) AS u(s1,s2) WHERE ...
(The SRF invocations might be buried inside expressions, but we'd find
them and convert them anyway. Also, we'd merge textually-identical SRF
invocations into a single ROWS FROM entry to avoid multiple evaluation,
at least for SRFs not marked volatile.) Having done that, the executor's
support for SRFs in general expressions could be removed, a significant
savings.
One problem with this is that it only duplicates the current behavior
in cases where the SRFs all have the same period. But you could argue
that the current behavior in cases where they don't is widely considered
a bug anyway.
A possibly larger problem is that it causes the SRFs to be evaluated
before sorting/ordering/limiting. In view of the discussions that led
up to 9118d03a8, that could be a fatal objection :-(. Maybe we could
get around it with a different transformation, into a two-level query?
The above sketch doesn't really consider what to do with GROUP BY,
ORDER BY, etc, but maybe we could push those down into a sub-select
that becomes the first FROM item.
Anyway, that's food for thought not something that could realistically
happen right now.
regards, tom lane
