From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | James William Pye <flaw(at)rhid(dot)com> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clean-up callbacks for non-SR functions |
Date: | 2004-05-20 14:18:38 |
Message-ID: | 591.1085062718@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
James William Pye <flaw(at)rhid(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-20 14:41:05 | Re: add server include files to default installation? |
Previous Message | James William Pye | 2004-05-20 13:15:30 | Re: Clean-up callbacks for non-SR functions |