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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers