plperl arginfo

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

2010/10/28 Andrew Dunstan <andrew@dunslane.net>:

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 ?

variadic

Pavel

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

On 10/28/2010 11:54 AM, Pavel Stehule wrote:

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()

Yeah, that looks doable.

I think we can just commit the generic record support now and add this
on later.

cheers

andrew

2010/10/28 Andrew Dunstan <andrew@dunslane.net>:

On 10/28/2010 11:54 AM, Pavel Stehule wrote:

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()

Yeah, that looks doable.

I think we can just commit the generic record support now and add this on
later.

this can be very interesting feature - because it can to do some
things in plperi instead c.

regards

Pavel

Andrew Dunstan <andrew@dunslane.net> writes:

On 10/28/2010 11:54 AM, Pavel Stehule wrote:

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()

Yeah, that looks doable.

BTW, maybe we could have the best of both worlds? Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only if it's actually touched. Passing the data as a hash definitely
seems to fit with the spirit of things otherwise, so as long as it
didn't cost cycles when not needed, I'd be in favor of that API.

regards, tom lane

On Thu, Oct 28, 2010 at 11:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 10/28/2010 11:54 AM, Pavel Stehule wrote:

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()

Yeah, that looks doable.

BTW, maybe we could have the best of both worlds?  Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only if it's actually touched.  Passing the data as a hash definitely
seems to fit with the spirit of things otherwise, so as long as it
didn't cost cycles when not needed, I'd be in favor of that API.

Perl has the tie interface (perldoc perltie) which lets you tie a hash
to an object instance, which implements subs to handle the various
hash operations.

On 10/28/2010 12:34 PM, Tom Lane wrote:

BTW, maybe we could have the best of both worlds? Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only if it's actually touched. Passing the data as a hash definitely
seems to fit with the spirit of things otherwise, so as long as it
didn't cost cycles when not needed, I'd be in favor of that API.

Maybe, but I think that's getting rather beyond my perlguts-fu. I think
we'd need to do that via PERL_MAGIC_tied, but it's new territory for me.
Anyone else want to chime in?

cheers

andrew

On Thu, Oct 28, 2010 at 01:03:24PM -0400, Andrew Dunstan wrote:

On 10/28/2010 12:34 PM, Tom Lane wrote:

BTW, maybe we could have the best of both worlds? Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only if it's actually touched. Passing the data as a hash definitely
seems to fit with the spirit of things otherwise, so as long as it
didn't cost cycles when not needed, I'd be in favor of that API.

Maybe, but I think that's getting rather beyond my perlguts-fu. I think
we'd need to do that via PERL_MAGIC_tied, but it's new territory for me.
Anyone else want to chime in?

Warning, I don't know the plperl, I am just a perl coder.

I do think all the anonymous array are worth worrying about in terms of
performance.

I don't think that tie is necessarily good for performance. tie() is not
generally fast. I think you'd likely be better off writing plain accessors
or using a function to add type info.

Use an accessor for type information, like this?
$ref->typeof($key)

...
or perhaps use a special function?

add_type_info(\%args);

...
or if you want attibute based syntax sugar for the add_type_info() solution...

my %args : pg_record(add_type_info);

Again, these I don't know the plperl code, so I might be missing something
here.

Garick

On 10/28/2010 02:11 PM, Garick Hamlin wrote:

On Thu, Oct 28, 2010 at 01:03:24PM -0400, Andrew Dunstan wrote:

On 10/28/2010 12:34 PM, Tom Lane wrote:

BTW, maybe we could have the best of both worlds? Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only if it's actually touched. Passing the data as a hash definitely
seems to fit with the spirit of things otherwise, so as long as it
didn't cost cycles when not needed, I'd be in favor of that API.

Maybe, but I think that's getting rather beyond my perlguts-fu. I think
we'd need to do that via PERL_MAGIC_tied, but it's new territory for me.
Anyone else want to chime in?

Warning, I don't know the plperl, I am just a perl coder.

I do think all the anonymous array are worth worrying about in terms of
performance.

I don't think that tie is necessarily good for performance. tie() is not
generally fast. I think you'd likely be better off writing plain accessors
or using a function to add type info.

Use an accessor for type information, like this?
$ref->typeof($key)

...
or perhaps use a special function?

add_type_info(\%args);

...
or if you want attibute based syntax sugar for the add_type_info() solution...

my %args : pg_record(add_type_info);

Again, these I don't know the plperl code, so I might be missing something
here.

This wouldn't be done at the perl level. It would be done in C code. Run
"man perlguts" and search for "Understanding the Magic of Tied Hashes
and Arrays". The overhead in setting it up is likely to be very low
unless I'm not understanding correctly. There might be some price paid
when accessing the object, but that's another affair.

OTOH, a pg_get_arg_info() function would probably be a substantially
simpler if slightly less perlish solution.

cheers

andrew