On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote: > 2008/8/23 Tom Lane <[EMAIL PROTECTED]>: > > Hannu Krosing <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers