Re: Status of plperl inter-sp calling

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Status of plperl inter-sp calling
Date: 2010-01-06 14:46:26
Message-ID: 1699.1262789186@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> writes:
> For my own benefit, being a PostgreSQL novice, could you expand a little?
> For example, given two stored procedures, A and V, where V is marked
> VOLATILE and both are plperl. How would having A call V directly, within
> the plperl interpreter, cause problems?

That case is fine. The problem would be in calling, say, VOLATILE from
STABLE. Any SPI queries executed inside the VOLATILE function would
need to be handled under read-write not read-only rules.

Now it's perhaps possible for you to track that yourself and make sure
to call SPI with the right arguments for the type of function you're
currently in, even if you didn't get to it via the front door. But
that's a far cry from "ignoring" the volatility property. It seems
nontrivial to do if you try to set things up so that no plperl code is
executed during the transition from one function to another.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-06 14:49:14 Re: Status of plperl inter-sp calling
Previous Message Robert Haas 2010-01-06 14:43:22 fastgetattr & isNull