2010/10/28 Tom Lane <t...@sss.pgh.pa.us>: > Andrew Dunstan <and...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers