Thread: plperl arginfo

plperl arginfo

From
Andrew Dunstan
Date:
<tt>While we were discussing allowing generic record type arguments to plperl functions, Tom suggested that we should
exposethe type information about the record members to plperl. I think if we do that we should probably expand it
somewhatto all arguments, so that for non-trigger functions, we'd have $_ARG_INFO while could look something like
this:<br/><br /></tt><blockquote><tt>{</tt><br /><tt>    names => ['arg1', undef, 'arg3' ] , # no name was supplied
forarg2</tt><br /><tt>    modes => ['in', 'in', 'in' ], # do we support anything other than IN ?</tt><br /><tt>   
types=> ['integer', 'text', { name => 'somecomposite', fields => [ 'field1', 'field2' ], types => ['date',
'numeric'] } ],</tt><br /><tt>}</tt><br /></blockquote><tt>Maybe we should also pass in type Oid info, too.<br /><br />
Idon't think this would be terribly difficult to do.<br /><br /> thoughts?<br /><br /> cheers<br /><br /> andrew<br
/><br/><br /><br />         <br /></tt> 

Re: plperl arginfo

From
Tom Lane
Date:
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


Re: plperl arginfo

From
Pavel Stehule
Date:
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

>     types => ['integer', 'text', { name => 'somecomposite', fields => [
> 'field1', 'field2' ], types => ['date', 'numeric' ] } ],
> }
>
> Maybe we should also pass in type Oid info, too.
>
> I don't think this would be terribly difficult to do.
>
> thoughts?
>
> cheers
>
> andrew
>
>
>
>
>


Re: plperl arginfo

From
Pavel Stehule
Date:
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
>


Re: plperl arginfo

From
Andrew Dunstan
Date:

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


Re: plperl arginfo

From
Tom Lane
Date:
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


Re: plperl arginfo

From
Pavel Stehule
Date:
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


>
> cheers
>
> andrew
>


Re: plperl arginfo

From
"Stephen J. Butler"
Date:
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.


Re: plperl arginfo

From
Andrew Dunstan
Date:

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




Re: plperl arginfo

From
Garick Hamlin
Date:
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


> 
> cheers
> 
> andrew
> 
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


Re: plperl arginfo

From
Andrew Dunstan
Date:

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