On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund <and...@anarazel.de> wrote: > This yields plenty weird behaviour in < v10. E.g. the following is > disallowed: > SELECT * FROM int4mul(generate_series(1,3), 1); > ERROR: 0A000: set-valued function called in context that cannot accept a > set > as is > SELECT * FROM CAST(int4mul(generate_series(1,3), 1) AS bigint); > ERROR: 0A000: set-valued function called in context that cannot accept a > set > because the cast is implemented as int8(expr) which avoids the fallback > path as it's a FuncExpr, but > SELECT * FROM CAST(int4mul(generate_series(1,3), 1) AS text); > works because the cast is implemented as a io coercion, which is not a > funcexpr. Therefore it uses the fallback ExecEvalExpr().
I don't think it's remotely reasonable to try to reproduce this kind of behavior exactly. I think the question is: if we do nothing here, will users be pissed? The answer is not clear to me. Rushabh's original report cast this as a possible bug, not a query he actually needed to work for any particular real-world purpose. On the other hand, I don't quite understand why any of these examples should fail. If you can select from generate_series() as if it were a table, it seems like you ought to be able to also apply one or more functions to the result and select from the result. On the third hand, if this only sort of half-worked in v9.6, it's hard to say it's a must-have for v10. So I'm not sure what the right thing to do here is. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
