On Sun, Jul 24, 2016 at 9:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: > >> Wouldn't it be better, if each nested sub-block (which is having an >> exception) has a separate "SPI Proc", "SPI Exec" contexts which would >> be destroyed at sub-block end (either commit or rollback)? > > AFAICS that would just confuse matters. In the first place, plpgsql > variable values are not subtransaction-local, so they'd have to live in > the outermost SPI Proc context anyway. In the second place, spi.c > contains a whole lot of assumptions that actions like saving a plan are > tied to the current SPI Proc/Exec contexts, so SPI-using plpgsql > statements that were nested inside a BEGIN/EXCEPT would probably break: > state they expect to remain valid from one execution to the next would > disappear. >
I think for all such usage, we can always switch to top level SPI Proc/Exec context. To do so, we might need to invent a notion of something like Sub SPI Proc/Exec contexts and that sounds quite tricky. >> In short, why do you think it is better to create a new context rather >> than using "SPI Exec"? > > "SPI Exec" has the same problem as the eval_econtext: there are already > points at which it will be reset, and those can't necessarily be delayed > till end of statement. In particular, _SPI_end_call will delete whatever > is in that context. > That's right and I think it might not be even feasible to do so, mainly because that is done in exposed SPI calls. I have checked some other usage of SPI, it seems plperl is handling some similar problems either via creating temporary work context or by using PG_TRY/PG_CATCH. I think it might be better if, whatever we are trying here could be of help for other similar usage. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers