On Wed, Jan 06, 2010 at 11:14:38AM -0500, Tom Lane wrote: > Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
