From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: suspicious pointer/integer coersion |
Date: | 2005-07-11 02:20:41 |
Message-ID: | 42D1D779.4040302@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
> Tom Lane wrote:
>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> 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 not have been much of an issue before
>> we had SPI support in plperl, since there was no way to recurse;
>> but it is an issue now.)
>
>
> Behaviour is not good (see below for proof).
>
> ISTM we'll need some sort of implicit of explicit stack of per-call
> data. The trick will be getting it to behave right under error recovery.
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Satoshi Nagayasu | 2005-07-11 03:13:20 | Re: A couple of p.tches for PostgreSQL 64bit support |
Previous Message | Andrew Dunstan | 2005-07-11 00:10:24 | Re: suspicious pointer/integer coersion |