From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) |
Date: | 2017-04-13 17:09:53 |
Message-ID: | 20170413170953.fovet363drh55hs6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-04-13 12:53:27 -0400, Robert Haas wrote:
> On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund <andres(at)anarazel(dot)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.
I'd say it really didn't work at v9.6, and it wasn't intended to,
there's always[TM] been explicit code to check for that:
/* We don't allow sets in the arguments of the table function */
if (argDone != ExprSingleResult)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("set-valued function called in context that cannot accept a set")));
it's just that it ended up not being entirely reliably checked...
I think there's some argument to be made that SRF in arguments ought to
work for reasons of consistency, but the required complications and the
lack of field demand make me skeptical about it being worth it.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-04-13 17:27:39 | Re: Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) |
Previous Message | Andres Freund | 2017-04-13 17:06:14 | Re: Cutting initdb's runtime (Perl question embedded) |