Re: SPI nesting in plperl

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: SPI nesting in plperl
Date: 2009-01-06 18:46:28
Message-ID: 9395.1231267588@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> I tried fixing this
> http://archives.postgresql.org/pgsql-general/2009-01/msg00030.php
> by inserting SPI_push/SPI_pop calls around plperl's use of
> InputFunctionCall and OutputFunctionCall ...

> I also thought about attacking the problem by having InputFunctionCall
> and OutputFunctionCall automatically do SPI_push/SPI_pop if they are
> called within an active SPI context. I don't like this approach too
> much because it seems likely to mask bugs as often as fix them. (In
> particular I'd be afraid to back-patch such a change.) It might be the
> cleanest solution overall, though, particularly when you consider that
> we've probably got similar issues in pltcl, plpython, and add-on PLs.

I've done a trial patch along the second line, and on the whole I think
it's probably far safer than sprinkling the system with SPI_push/SPI_pop
calls. Comments?

regards, tom lane

Attachment Content-Type Size
unknown_filename text/plain 8.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martin Pihlak 2009-01-06 18:48:01 Re: dblink vs SQL/MED - security and implementation details
Previous Message Tom Lane 2009-01-06 18:40:28 Is it really such a great idea for spi.h to include the world?