Re: Initial review of xslt with no limits patch

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Mike Fowler <mike(at)mlfowler(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Initial review of xslt with no limits patch
Date: 2010-08-06 18:10:08
Message-ID: AANLkTikZku+6zQvPziaoVU5r514=JzCbgNAGB-Mk4roj@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/8/6 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2010-08-06 18:12:16 Re: including backend ID in relpath of temp rels - updated patch
Previous Message Tom Lane 2010-08-06 18:07:31 Re: including backend ID in relpath of temp rels - updated patch