From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Decibel! <decibel(at)decibel(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: proposal sql: labeled function params |
Date: | 2008-08-24 07:52:07 |
Message-ID: | 1219564327.26201.13.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
> 2008/8/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> > Hannu Krosing <hannu(at)2ndQuadrant(dot)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 :).
This is "labeled params", or rather variadic hstore. done this way, it
has added benefit over single hstore param, that "key" or "label" can be
repeated:
select myfunc('name' => 'bob', 'age'=>'42', 'name' => 'bill', ...);
same as
select myfunc2(select('bob' as name, 42 as age, 'bill' as name, ...));
> 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.
-------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2008-08-24 07:57:29 | Re: Proposal: new border setting in psql |
Previous Message | Pavel Stehule | 2008-08-24 06:05:00 | Re: proposal sql: labeled function params |