Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
От | Tim Bunce |
---|---|
Тема | Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl |
Дата | |
Msg-id | 20100217122828.GV373@timac.local обсуждение исходный текст |
Ответ на | Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
|
Список | pgsql-hackers |
On Tue, Feb 16, 2010 at 02:13:30PM -0800, David E. Wheeler wrote: > On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote: > > >>> For varadic functions, separate plans are created and cached for each distinct > >>> number of arguments the function is called with. > >> > >> Why? > > > > It keeps the code simple and repeat calls fast. > > Yes, but if it's a variadic function, I suspect that it won't often be > called with the same number of args. So you'd potentially end up > caching a lot of extra stuff that would never be used again. Potentially. Patches welcome! > >> So, is this on GitHub yet? That way I can submit patches. > > > > I've uploaded PostgreSQL-PLPerl-Call-1.003.tar.gz to CPAN with these > > changes. It's in git but not github yet. Maybe soonish. > > I saw. I think it might pay to heed Richard's suggestion not to use "SP". Umm, perhaps F->funcname(@args), or PG->funcname(@args), or ... ? Anyone got any better suggestions? > By the way, I think it needs some documentation explaining how to load it inside PL/Perl. I thought about that, and started to write it, but dropped it for now. I'll wait till my "cunning plan" to share code with the Safe compartment (aka PostgreSQL::PLPerl::Injector) is done then document how call() can be used in both plperlu and plperl. Tim.
В списке pgsql-hackers по дате отправления: