Re: Initial review of xslt with no limits patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Initial review of xslt with no limits patch
Date
Msg-id AANLkTimnc55xs-fAK2gBH3C=2tbGXRMK0jhBS3KCZ67F@mail.gmail.com
Whole thread Raw
In response to Re: Initial review of xslt with no limits patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Initial review of xslt with no limits patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Initial review of xslt with no limits patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule <pavel.stehule@gmail.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.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: including backend ID in relpath of temp rels - updated patch
Next
From: Andres Freund
Date:
Subject: Cost of AtEOXact_Buffers in --enable-cassert