Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Rushabh Lathia <rushabh.lathia@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-04-12T18:45:23Z
Lists: pgsql-hackers
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
Commits
-
Provide an error cursor for "can't call an SRF here" errors.
- e240a65c7dfc 10.0 landed
-
Pass the source text for a parallel query to the workers.
- 4c728f382970 10.0 cited
-
Move targetlist SRF handling from expression evaluation to new executor node.
- 69f4b9c85f16 10.0 cited