On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund <andres@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