Joe Conway <[EMAIL PROTECTED]> writes:
> OK -- this one is a good bit simpler. Any more comments?
Looks good to me. Please apply to 7.4 and HEAD.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list
Tom Lane wrote:
You may not even need to add any fields to FuncCallContext --- consider
passing the fcinfo pointer to the callback, rather than passing the
FuncCallContext pointer.
Dept. of second thoughts: better pass the flinfo pointer, instead.
fcinfo might point to temporary space on the stack.
> You may not even need to add any fields to FuncCallContext --- consider
> passing the fcinfo pointer to the callback, rather than passing the
> FuncCallContext pointer.
Dept. of second thoughts: better pass the flinfo pointer, instead.
fcinfo might point to temporary space on the stack.
Joe Conway <[EMAIL PROTECTED]> writes:
> Any comment on the patch?
It seems like a bad idea to change the contents of the SRF_XXX() macros
for 7.4.1; if we do that, any existing already-compiled-for-7.4 user
SRFs will be broken, and there's no easy way to catch the problem.
We don't normally requi
> Tom Lane wrote:
>> [ scratches head ... ] Right at the moment I don't see where
>> ShutdownExprContext gets called during a ReScan operation. I'm quite
>> sure it once was ... there may be another bug here ...
After further looking I've realized that memory is misserving me here;
having ReScan
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Any guidance on the preferred fix?
We cannot fix this by changing ExecScanSubPlan as you suggest.
That would amount to saying that all plans have to be run to completion,
which destroys LIMIT to name just one unpleasant consequence.
I suspected
Jeff Rogers <[EMAIL PROTECTED]> writes:
> However, the documentation says that using a SRF in the select list of
> a query, but this capability is deprecated. I can't figure out how to
> call this function in the from clause with it referring to a column in
> a table, I get an error like
> ERROR:
