On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote: > The signature doesn't just qualify the selection of the function, > it also ensures appropriate interpretation of the arguments. > > I could allow call('foo', @args), which could be written call(foo => @args), > but what should that mean in terms of the underlying behaviour? > > I think there are three practical options: > a) treat it the same as call('foo(unknown...)', @args)
I believe that's basically what psql does. It's certainly what DBD::Pg does. > b) treat it the same as call('foo(text...)', @args) Probably not a great idea. > c) instead of using a cached prepared query, build an SQL statement > for every execution, which would naturally have to quote all values: > my $args = join ",", map { ::quote_nullable($_) } @_; > return ::spi_exec_query("select * from $spname($args)"); > > I suspect there are subtle issues (that I'm unfamilar with) lurking here. > I'd appreciate someone with greater understanding spelling out the issues > and trade-offs in those options. I'm pretty sure the implementation doesn't have to declare the types of anything: sub AUTOLOAD { my $self = shift; our $AUTOLOAD; (my $fn = $AUTOLOAD) =~ s/.*://; my $prepared = spi_prepare( 'EXECUTE ' . quote_ident($fn) . '(' . join(', ', ('?') x @_) . ')'; # Cache it and call it. } > Umm, > tl_activity_stats_sql => [qw(text[] int)] > > seems to me longer and rather less visually appealing than > > 'tl_activity_stats_sql(text[], int)' That would work, too. But either way, having to specify the signature would be the exception rather than the rule. You'd only need to do it when calling a polymorphic function with the same number of arguments as another polymorphic function. >> and only provide the signature when I need to disambiguate between >> polymorphic variants. > > Or need to qualify the type of the argument for some other reason, like > passing an array reference. I don't think it's necessary. I mean, if you're passed an array, you should of course pass it to PostgreSQL, but it can be anyarray. > But perhaps we can agree on one of the options a/b/c above and then > this issue will be less relevant. It's not like you'd be saving much > typing: > > call('tl_activity_stats_sql', @args) > call(tl_activity_stats_sql => @args) > SP->tl_activity_stats_sql(@args) No, but the latter is more Perlish. > You could always add a trivial SP::AUTOLOAD wrapper function to your > plperl.on_init code :) Yeah yeah. I could even put one on CPAN. ;-P But where are you caching planned functions? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers