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.
regards, tom lane
