Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-04-11 17:25:52 -0400, Tom Lane wrote:
>> What was the previous behavior for such cases? If it was reasonably
>> sane, we probably have to preserve it. If it was unpredictable or
>> completely wacko, maybe we don't.

> Previously we'd stash the result in a new tuplestore, because it
> happened inside ExecMakeTableFunctionResult()'s fallback path. The
> inner tuplestore (from the proper SRF) would get evaluated via the the
> isDone mechanism.

> That'd imo be a fair amount of work to emulate, because we'd have to
> manually go over the tuplesttore.

Yeah. I don't have a big problem with saying that things that aren't
themselves SRFs are evaluated as though in a projection step atop the
SRF calculation. We've already crossed that bridge with respect to
expressions around SRFs in the tlist --- for instance this:

regression=# select f1, case when f1>0 then generate_series(1,2) else null end as c from int4_tbl;
f1 | c
-------------+---
0 |
0 |
123456 | 1
123456 | 2
-123456 |
-123456 |
2147483647 | 1
2147483647 | 2
-2147483647 |
-2147483647 |
(10 rows)

gives different results than it used to:

regression96=# select f1, case when f1>0 then generate_series(1,2) else null end as c from int4_tbl;
f1 | c
-------------+---
0 |
123456 | 1
123456 | 2
-123456 |
2147483647 | 1
2147483647 | 2
-2147483647 |
(7 rows)

Now, that old behavior matches what you got in the RangeFunction case:

regression96=# select * from int4_tbl, cast(case when f1>0 then generate_series(1,2) else null end as int);
f1 | int4
-------------+------
0 |
123456 | 1
123456 | 2
-123456 |
2147483647 | 1
2147483647 | 2
-2147483647 |
(7 rows)

So it would make sense to me for our new behavior to still match the
targetlist case.

Not sure if that's exactly the same as what you're saying or not.

regards, tom lane