Re: plperl arginfo

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Subject: Re: plperl arginfo
Date: 2010-10-28 15:39:11
Message-ID: 16686.1288280351@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-10-28 15:39:31 Re: plperl arginfo
Previous Message Jesper Krogh 2010-10-28 15:28:53 Re: Postgres insert performance and storage requirement compared to Oracle