2010/10/28 Tom Lane <tgl@sss.pgh.pa.us>:
> Andrew Dunstan <andrew@dunslane.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>