Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f)
Date
Msg-id 20170413170953.fovet363drh55hs6@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause(Commit id: 69f4b9c85f)  (Robert Haas <robertmhaas@gmail.com>)
List 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@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.

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
calledin 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)