Re: Initial review of xslt with no limits patch

2010/8/6 Robert Haas :
> On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule  wrote:
>> I'll propose a new kind of functions (only position parameter's
>> function). My idea is simple - for functions with this mark the mixed
>> and named notation is blocked. But these functions can have a
>> parameter names - and these names can be passed to function. So there
>> is possible have a
>>
>> xslt_process function with current behave - third argument has not
>> label, and new variadic version like
>>
>> xslt_process(..,.., param_name1 = 'v1', param_name2 = 'v2',
>> param_name3 = 'v3', ...)
>>
>> an implementation of this functionality can be very simple, and we can
>> use this for xslt_process in 9.1
>
> Why wouldn't we just pass two text arrays to this function and be done
> with it?  Custom syntax is all well and good when you're writing these
> calls by hand, but it's not hard to imagine someone wanting to pass in
> values stored somewhere else.

yes, it is possible too. And maybe is better then current
xslt_process. But it isn't too much readable and robust. You have to
calculate position of name and position of value. This is same in
other languages. You can use a dynamic parameters in PHP or Perl via
two arrays, but nobody use it. People use a hash syntax (param1=>val,
param2=>val). This proposal isn't only for xslt_process function. Why
hstore has a custom parser? It can use only a pair of arrays too.

For Tom: proposed syntax can be used generally - everywhere when you
are working with collection. It can be used for hash (hstore)
constructor for example. For me is more readable code like

select hstore(name := 'Tomas', surname := 'Novak')

than

select hstore('name=\'Tomas\', surname=\'Novak\'')

The main advance of this feature is simplicity of custom functions.
Its must not have a custom parser. So possible an using is hstore,
xslt_process

Regards

Pavel Stehule


>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>