Re: Status of plperl inter-sp calling

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