Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)
От
Andres Freund
Тема
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)
Дата
Msg-id
20170412184523.agr3f7vt2gzpdmvi@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
[HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Rushabh Lathia <rushabh.lathia@gmail.com>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: Query fails when SRFs are part of FROM clause (Commit id:69f4b9c85f) Noah Misch <noah@leadboat.com>
Re: Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f) Noah Misch <noah@leadboat.com>
Re: Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f) Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f) Andres Freund <andres@anarazel.de>
Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Stephen Frost <sfrost@snowman.net>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) "David G. Johnston" <david.g.johnston@gmail.com>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) Rushabh Lathia <rushabh.lathia@gmail.com>
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) "David G. Johnston" <david.g.johnston@gmail.com>
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
В списке pgsql-hackers по дате отправления
От: Robert Haas
Дата:
От: Andreas Karlsson
Дата: