Re: Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

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

In response to

Browse pgsql-hackers by date

  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)