On Wed, Jan 06, 2010 at 11:14:38AM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Tom Lane wrote:
> >> spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > OK, but won't that automatically supply the value from the function
> > called from postgres, which will be the right thing?
>
> My point was that that is exactly the wrong thing. If I have a function
> declared stable, it must not suddenly start behaving as volatile because
> it was called from a volatile function. Nor vice versa.
>
> Now as I mentioned upthread, there might be other ways to get the
> correct value of the readonly parameter. One that comes to mind is
> to somehow attach it to the spi call "at compile time", whatever that
> means in the perl world. But you can't just have it be determined by
> the outermost active function call.
If you want 'a perl compile time hook', those are called attributes.
http://search.cpan.org/~dapm/perl-5.10.1/lib/attributes.pm
You can define attributes to effect how a given syntax compiles.
perl.
my $var :foo;
or
sub bar :foo;
The subroutine or variable is compiled in a way defined by the
':foo' attribute.
This might be a clean way around the type dispatch issues
as well. One could include the invokant type information in the
perl declaration.
sub sp_something :pg_sp ('bigint bigint');
sp_something ("12",0);
Anyway, that looks like a nice interface to me...
Although, I don't understand the Pg internals problem faced here
so ... I'm not sure my suggestion is helpful.
Garick
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
