Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) |
Дата | |
Msg-id | 8875.1485813356@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)
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: >> SELECT * >> FROM pg_constraint pc, >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, >> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position; >> >> Above query is failing with "set-valued function called in context that >> cannot accept a set". > I think that's correct. Functions in FROM are essentially a shorthand > for ROWS FROM(). And ROWS FROM doesn't allow arbitrary expressions. No, but it allows whatever looks syntactically like a function, including casts. IIRC, we made func_expr work that way ages ago to deflect complaints that it wasn't very clear why some things-that-look-like- functions were allowed in CREATE INDEX and others not. > If, I didn't check, that worked previously, I think that was more > accident than intent. Yeah, probably. But are we prepared to break working queries? As I understood it, the agreement on this whole tlist-SRF change was that we would not change any behavior that wasn't ill-defined. We could probably fix this with the modification that was discussed previously, to allow FunctionScan nodes to project a scalar tlist from the outputs of their SRFs. regards, tom lane
В списке pgsql-hackers по дате отправления: