Joe Conway <[EMAIL PROTECTED]> writes:
> Any ideas on getting (node->scan.plan.chgParam != NULL) to be true?
You need something that passes a parameter into the scan node.
I think the only thing that would do it is a subquery that references
an outer-level variable, for example
select * from foo
Tom Lane wrote:
> I am still concerned about whether ExecFunctionReScan works correctly;
> if not, the problems would show up in join and subquery situations.
> I think the parser and planner stages are in pretty good shape now,
> though. (At least as far as the basic functionality goes. Having
Joe Conway <[EMAIL PROTECTED]> writes:
> Actually I found late last night that when the view is used, the RTE is
> a RangeVar, so the RangeFunction code never gets executed. So I think
> your comment above is right on. That may well explain both problems.
Hmm. I thought your view problems wer
Tom Lane wrote:
> Um, that's probably not it then. Rescan would only come into play for
> a plan node that's being used as the inside of a join, or some other
> contexts more complicated than this. A simple view ought to make no
> difference at all in the generated plan --- perhaps there's some
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It's not unlikely that those issues are exactly due to not having rescan
>> handled properly. What misbehavior are you seeing?
> Hmm, that might just be it.
> When I select from a view based on a function which returns a base type,
>
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>>... I have not started RescanExprContext() yet, but will do it
>>when I address rescans in general.
>
>>I still have a couple of issues related to VIEWs that I need to figure
>>out, then I'll start the rescan work.
>
> It's not unlikel
Joe Conway <[EMAIL PROTECTED]> writes:
> ... I have not started RescanExprContext() yet, but will do it
> when I address rescans in general.
> I still have a couple of issues related to VIEWs that I need to figure
> out, then I'll start the rescan work.
It's not unlikely that those issues are
Tom Lane wrote:
> Um. I don't like that; it assumes not only that ExecutorEnd is the only
> kind of callback needed, but also that there is at most one function
> per ExprContext that needs a shutdown callback. Neither of these
> assumptions hold water IMO.
>
> The design I had in mind was more
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Adding a list of callbacks to
>> ExprContext seems pretty reasonable, but you'd also need some link in
>> ReturnSetInfo to let the function find the ExprContext to register
>> itself with. Then FreeExprContext would call the callbacks.
Tom Lane wrote:
> I don't much care for the thought of trawling every expression tree
> looking for functions-returning-set during plan shutdown, so the thought
> that comes to mind is to expect functions that want a shutdown callback
> to register themselves somehow. Adding a list of callbacks t
Joe Conway <[EMAIL PROTECTED]> writes:
> Just now I was looking for a way to propagate the necessary information
> to call ExecutorEnd() from ExecEndFunctionScan() in the case that fmgr
> doesn't. It looks like I might be able to add a member to the
> ExprContext struct for this purpose. Does t
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>>With the current SRF patch, in certain circumstances selecting from a
>>VIEW produces "Buffer Leak" warnings, while selecting from the function
>>itself does not. Also the VIEW returns only one of the two expected
>>rows.
>
> The bu
Joe Conway <[EMAIL PROTECTED]> writes:
> With the current SRF patch, in certain circumstances selecting from a
> VIEW produces "Buffer Leak" warnings, while selecting from the function
> itself does not. Also the VIEW returns only one of the two expected
> rows.
The buffer leak suggests failur
Valentine Zaretsky wrote:
> just_fun=# select * from fun(1) as fun limit 1;
> WARNING: Buffer Leak: [050] (freeNext=-3, freePrev=-3, rel=16570/16587,
> blockNum=0, flags=0x85, refcount=1 2)
> i | v
> ---+-
> 1 | one
> (1 row)
>
> And there is no warning with "ORDER BY"
>
> just_fun=#
Hello, Joe!
JC> With the current SRF patch, in certain circumstances selecting from
JC> a
JC> VIEW produces "Buffer Leak" warnings, while selecting from the
JC> function itself does not. Also the VIEW returns only one of the two
Selecting from the function produces such a warning when using
With the current SRF patch, in certain circumstances selecting from a
VIEW produces "Buffer Leak" warnings, while selecting from the function
itself does not. Also the VIEW returns only one of the two expected
rows. The same SQL function when declared as "... getfoo(int) RETURNS
int AS ..." in
16 matches
Mail list logo
