Joe Conway writes:
> That's what I was thinking. I saw your other email about LATERAL for 9.1
> -- would it be helpful for me to work on this issue for 9.1? After all,
> about 7 years ago I said I'd do it ;-). Or do you think it will be an
> integral part of the LATERAL work?
Dunno. What I was a
On 05/08/2010 09:12 AM, Tom Lane wrote:
> Joe Conway writes:
>> I think this is an example of why we still need to implement a real
>> SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
>> ValuePerCall sort of works from the targetlist, but it is pretty much
>> useless for the use ca
Joe Conway writes:
> I think this is an example of why we still need to implement a real
> SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
> ValuePerCall sort of works from the targetlist, but it is pretty much
> useless for the use cases where people really want to use it.
> Or
On 05/07/2010 09:06 PM, Nikhil Sontakke wrote:
>>> Yeah this is my basic confusion. But wouldn't the arguments be
>>> evaluated afresh on the subsequent call for this SRF?
>>
>> No, see ExecMakeFunctionResult(). If we did that we'd have serious
>> problems with volatile functions, ie srf(random())
Nikhil Sontakke writes:
> Ok thanks. So if someone uses a really long-running srf with argument
> expression evaluations thrown in, then running into "out of memory"
> issues should be expected and then in those cases they are better off
> using multiple srf calls to get the same effect if they ca
>> Yeah this is my basic confusion. But wouldn't the arguments be
>> evaluated afresh on the subsequent call for this SRF?
>
> No, see ExecMakeFunctionResult(). If we did that we'd have serious
> problems with volatile functions, ie srf(random()).
>
Ok thanks. So if someone uses a really long-run
Nikhil Sontakke writes:
>> Consider
>> srf(foo(col))
>> where foo returns a pass-by-reference datatype.
> Yeah this is my basic confusion. But wouldn't the arguments be
> evaluated afresh on the subsequent call for this SRF?
No, see ExecMakeFunctionResult(). If we did that we'd have seri
Hi,
>> Can someone please explain why we do not reset the expression context
>> if an SRF is involved during execution?
>
> Consider
> srf(foo(col))
> where foo returns a pass-by-reference datatype. Your proposed patch
> would cut the knees out from under argument values that the SRF could
Nikhil Sontakke writes:
> Can someone please explain why we do not reset the expression context
> if an SRF is involved during execution?
Consider
srf(foo(col))
where foo returns a pass-by-reference datatype. Your proposed patch
would cut the knees out from under argument values that the
> Patch attached with this mail.
>
The previous patch was WIP. Please take a look at this one instead. I
hope this handles the cases where results are not just base datums but
palloc'ed datums like string types too.
Regards,
Nikhils
> The SRF has its own long-lived "SRF multi-call context" anywa
Hi,
Continuing on this:
Can someone please explain why we do not reset the expression context
if an SRF is involved during execution? Once the current result from
the SRF has been consumed, I would think that the
ecxt_per_tuple_memory context should be reset. As its name suggests,
it is supposed
Hi,
I saw this behavior with latest GIT head:
create table xlarge(val numeric(19,0));
insert into xlarge values(generate_series(1,5));
The above generate series will return an int8 which will then be
casted to numeric (via int8_to_numericvar) before being inserted into
the table. I observed that
12 matches
Mail list logo
