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