Обсуждение: plperl arginfo
<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>
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
> 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
>
>
>
>
>
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
>
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
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
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 >
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 > > 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
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