On Wed, Jan 6, 2010 at 9:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Tim Bunce <Tim.Bunce@pobox.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.
I think it's becoming clear that it's hopeless to make this work in a
way that is parallel to what will happen if you call these functions
via a real SPI call. Even if Tim were able to reimplement all of our
semantics in terms of what is immutable, stable, volatile,
overloading, default arguments, variadic arguments, etc., I am fairly
certain that we do not wish to maintain a Perl reimplementation of all
of our calling conventions which will then have to be updated every
time someone adds a new bit of magic to the core code.
I think what we should do is either (1) implement a poor man's caching
that doesn't try to cope with any of these issues, and document that
you get what you pay for or (2) reject this idea in its entirety.
Trying to reimplement all of our normal function call semantics in a
caching layer does not seem very sane.
...Robert
