Re: Clean-up callbacks for non-SR functions

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

In response to

Responses

Browse pgsql-hackers by date

  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