Re: proposal sql: labeled function params - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal sql: labeled function params
Date
Msg-id 162867790808232305t51219dccq56b941267bf5de15@mail.gmail.com
Whole thread Raw
In response to Re: proposal sql: labeled function params  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal sql: labeled function params  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
2008/8/23 Tom Lane <tgl@sss.pgh.pa.us>:
> Hannu Krosing <hannu@2ndQuadrant.com> writes:
>> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>>> record or hash table - it's implementation - second step. We have to
>>> find syntax and semantic now.
>
>> Why not just use some standard record syntax, like
>> SELECT(value::type name, ...)
>
> Yeah, that's one way.  It also strikes me that hstore itself provides a
> usable solution to this problem, though only for simple-string values.
> That is, you could do something like
>
>        create function myfunc(hstore) returns ...
>
>        select myfunc('tag1' => '42' || 'tag2' => 'foobar' || ...);
>
> Or, with the new variadic function support,
>
>        create function myfunc(variadic hstore[]) returns ...
>
>        select myfunc('tag1' => '42', 'tag2' => 'foobar', ...);
>
> which is just a couple of quote marks away from the syntax Pavel
> wants.
>

it's not far. I am only doesn't know if is it labeled params or named
params :). Using hstore is usable, but I dislike it. There is small
overhead and would to use named params for classic functions - with
different types and fixed count of params. I am thinking so first step
is implementation of defaults without named params like firebird. It's
less controversy.

regards
Pavel Stehule

>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: "D'Arcy J.M. Cain"
Date:
Subject: Re: Proposal: new border setting in psql
Next
From: Hannu Krosing
Date:
Subject: Re: proposal sql: labeled function params