Hi, On 2017-01-18 14:24:12 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-01-18 08:43:24 -0500, Tom Lane wrote: > >> ... except for one thing. The more I look at it, > >> the more disturbed I am by the behavioral change shown in rangefuncs.out > >> --- that's the SRF-in-one-arm-of-CASE issue. > > > I'm fine with leaving it as is in the patch, but I'm also fine with > > changing things to ERROR. Personally I don't think it matters much, and > > we can whack it back and forth as we want later. Thus I'm inclined to > > commit it without erroring out; since presumably we'll take some time > > deciding on what exactly we want to prohibit. > > I agree. If we do decide to throw an error, it would best be done in > parse analysis, and thus would be practically independent of this patch > anyway.
Cool, agreed then. > >> * This bit in ExecProjectSRF was no good: > >> + else if (IsA(gstate->arg, FuncExprState) && > >> + ((FuncExpr *) gstate->arg->expr)->funcretset) > > > Argh. That should have been FunExprState->func->fn_retset. > > Nope; that was my first thought as well, but fn_retset isn't valid if > init_fcache hasn't been run yet, which it won't have been the first time > through. Righty-O :( > So I think we can push this patch now and get on with the downstream > patches. Do you want to do the honors, or shall I? Whatever you prefer - either way, I'll go on to rebasing the cleanup patch afterwards (whose existance should probably be mentioned in the commit message). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
