On 2017-04-11 17:42:42 -0400, Tom Lane wrote:
> 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.
The patch now indeed returns
regression[20994][1]=# select * from int4_tbl, cast(case when f1>0 then generate_series(1,2) else null end as int);
WARNING: 01000: replacing
LOCATION: frobble_rtefunc, createplan.c:3102
(as you can see, this ain't quite ready)
┌─────────────┬────────┐
│ f1 │ int4 │
├─────────────┼────────┤
│ 0 │ (null) │
│ 0 │ (null) │
│ 123456 │ 1 │
│ 123456 │ 2 │
│ -123456 │ (null) │
│ -123456 │ (null) │
│ 2147483647 │ 1 │
│ 2147483647 │ 2 │
│ -2147483647 │ (null) │
│ -2147483647 │ (null) │
└─────────────┴────────┘
(10 rows)
The basic approach seems quite workable. It's not super extensible to
allow SRFs deeper inside generic ROWS FROM arguments however - I'm not
sure there's any need to work towards that however, I've not heard
demands so far. Any arguments against that?
One other thing where it'd currently affect behaviour is something like:
SELECT * FROM CAST(generate_series(1,0) * 5 as int);
which, in < v10 would return 1 row, but with my patch returns no rows.
That makes a lot more sense in my opinion, given that a plain FROM
generate_series(1,0) doesn't return any rows in either version.
Right now I'm mopping up corner cases where it'd *expand* the set of
currently valid commands in an inconsistent manner. Namely FROM
int4mul(generate_series(..), 5) works, but FROM
composite_returning(somesrf()) wouldn't without additional work. I plan
to continue to error out in either...
Greetings,
Andres Freund
