This seems to have gone AWOL in the email ether, so I am resending.
Original Message
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have just noticed this code in plperl.c:
hv_store(plperl_proc_hash, internal_proname, proname_len,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Attached is a patch that fixes (I hope) both a recently introduced
>> problem with recursion and a problem with array returns that became
>> evident as a result of not throwing away non-fatal warnings (thanks to
>> David Fetter for noticing this). Re
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Looking further ... we already do this implicitly for prodesc in the
call handler - we would just need to do the same thing for per-call
structures and divorce them from prodesc, which can be repeated on
the implicit stack.
I'll work on
Andrew Dunstan wrote:
Looking further ... we already do this implicitly for prodesc in the
call handler - we would just need to do the same thing for per-call
structures and divorce them from prodesc, which can be repeated on the
implicit stack.
I'll work on that - changes should be q
Looking further ... we already do this implicitly for prodesc in the
call handler - we would just need to do the same thing for per-call
structures and divorce them from prodesc, which can be repeated on the
implicit stack.
I'll work on that - changes should be quite small.
Sounds like recur
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Works for me. There are some other things about the procdesc stuff
I'm trying to sort out (especially if we should be storing per-call
info inside it).
Hmm, probably not ... check to see if a recursive
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Works for me. There are some other things about the procdesc stuff I'm
trying to sort out (especially if we should be storing per-call info
inside it).
Hmm, probably not ... check to see if a recursive plperl function
behav
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Works for me. There are some other things about the procdesc stuff I'm
> trying to sort out (especially if we should be storing per-call info
> inside it).
Hmm, probably not ... check to see if a recursive plperl function
behaves sanely. (This might
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have just noticed this code in plperl.c:
hv_store(plperl_proc_hash, internal_proname, proname_len,
newSViv((IV) prodesc), 0);
basically, here prodesc is a pointer to a struct, and we ar
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have just noticed this code in plperl.c:
> hv_store(plperl_proc_hash, internal_proname, proname_len,
> newSViv((IV) prodesc), 0);
> basically, here prodesc is a pointer to a struct, and we are storing it
> as an integer in a
I have just noticed this code in plperl.c:
hv_store(plperl_proc_hash, internal_proname, proname_len,
newSViv((IV) prodesc), 0);
basically, here prodesc is a pointer to a struct, and we are storing it
as an integer in a perl hash for easy lookup by stringified oid.
How
11 matches
Mail list logo
