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 |
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? |