Re: proposal sql: labeled function params
От | Pavel Stehule |
---|---|
Тема | Re: proposal sql: labeled function params |
Дата | |
Msg-id | 162867790808232305t51219dccq56b941267bf5de15@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal sql: labeled function params (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: proposal sql: labeled function params
|
Список | 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 по дате отправления: