Re: plperl arginfo

2010/10/28 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>   While we were discussing allowing generic record type arguments to
>> plperl functions, Tom suggested that we should expose the type
>> information about the record members to plperl. I think if we do that we
>> should probably expand it somewhat to all arguments, so that for
>> non-trigger functions, we'd have $_ARG_INFO while could look something
>> like this:
>
>>     {
>>          names => ['arg1', undef, 'arg3' ] , # no name was supplied for arg2
>>          modes => ['in', 'in', 'in' ], # do we support anything other
>>     than IN ?
>>          types => ['integer', 'text', { name => 'somecomposite', fields
>>     => [ 'field1', 'field2' ], types => ['date', 'numeric' ] } ],
>>     }
>
> Hmm, I'm a bit worried about the performance implications of adding this
> information.  It seems like the value in typical cases would be minimal:
> when you are writing the body of "myfunction(foo int, bar text)", it's
> not like you don't know perfectly well the names and argument types of
> the parameters.
>
> I can see the value of providing type info for polymorphic arguments,
> but not sure about expending extra cycles to do it for all.
>
> Alternatively, maybe the feature could be exposed in a way where you
> don't actually calculate the values unless requested, ie provide some
> sort of inquiry function instead of always precomputing a hash.

+1 .. some like get_function_info()

Regards

Pavel Stehule
>
>                        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
>