Hello
2008/8/24 Hannu Krosing <hannu@2ndquadrant.com>:
> On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
>> 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 :).
>
> 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, ...));
>
and actually, how far we are from original proposal
select myfunc(name => 'bob', age => 42 ...
this syntax is most cleaner, and doesn't need bigger changes in
parser, zero changes in PL
regards
Pavel
>> 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
>
>
>
