Re: Clean-up callbacks for non-SR functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Clean-up callbacks for non-SR functions
Date
Msg-id 591.1085062718@sss.pgh.pa.us
Whole thread Raw
In response to Re: Clean-up callbacks for non-SR functions  (James William Pye <flaw@rhid.com>)
Responses Re: Clean-up callbacks for non-SR functions  (James William Pye <flaw@rhid.com>)
List pgsql-hackers
James William Pye <flaw@rhid.com> writes:
> SELECT aFunction();
> Gives fcinfo->resultinfo != NULL, ONLY IF it is a SRF.(fn_retset != 0)

Indeed.  Since passing a ReturnSetInfo in resultinfo occurs only when
the system is expecting a set result (and is prepared to handle one),
I do not see what you would expect different here.

> I attached a simple patch that seems to make it work,

s/makes it work/breaks it/ ... this patch would effectively inform
functions that *aren't* supposed to return set that a set result is
expected.  Which would certainly break plpgsql, and probably any other
callee that is coded to handle both cases.

It's true that this setup doesn't allow non-SRFs to get at the econtext,
but I'm not sure that they need to.  We have not previously seen any
example where that's important.  If it really were important then we'd
need to invent a different result node type (*not* ReturnSetInfo) to
carry only econtext.  Such a function would however fail in situations
where there simply isn't any econtext, which I think includes a lot of
the system's internal uses.  So let's see the use-case first.
        regards, tom lane


pgsql-hackers by date:

Previous
From: James William Pye
Date:
Subject: Re: Clean-up callbacks for non-SR functions
Next
From: Tom Lane
Date:
Subject: Re: add server include files to default installation?