Andres Freund <andres@anarazel.de> writes:
> On 2017-04-17 19:26:11 -0400, Tom Lane wrote:
>> If we are going to go down this road, I think it would be a good idea
>> to try to provide a cursor position for the "can't accept a set" error
>> message, because otherwise it will be really unclear what's wrong with
>> something like
> Looks good to me.
Thanks for reviewing.
I did some further testing and noted that plperl and pltcl fail to pass
through the error cursor, although plpgsql and plpython seem OK. That's
a pre-existing issue though --- they don't pass through plain syntax
error cursors either. I'm fine with leaving that for later. Otherwise,
it seemed to work, so pushed.
> I couldn't find any place in the docs that actually documents our SRF
> behaviour in any sort of detail ([1], [2]), particularly not documenting
> where SRFs are legal, and how nested SRFs are supposed to behave. I'm
> not sure in how much detail we want to go? If we want do document that,
> where? The closest seems to be "4.2.14. Expression Evaluation Rules"
> [3].
Looks like you didn't notice xfunc.sgml? There's a large amount of info
there, particularly section 37.4.8:
https://www.postgresql.org/docs/devel/static/xfunc-sql.html#xfunc-sql-functions-returning-set
I've never been totally happy with this presentation, since (a) it's
buried pretty far in the back of the manual, and (b) structurally it
looks like it applies only to SQL-language functions, despite the
disclaimer that says it applies to all languages. Still, right now
is probably not the time to do massive docs surgery, and in any case
I'm not sure that bringing all that detail forward into 4.2 would
represent an improvement. Maybe a link or two from chapter
4 would be the ticket.
regards, tom lane
