| 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: | Whole Thread | Raw Message | 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? |