Re: proposal sql: labeled function params
От | Pavel Stehule |
---|---|
Тема | Re: proposal sql: labeled function params |
Дата | |
Msg-id | 162867790808240113i7986c634g60a01bffcec50c76@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal sql: labeled function params (Hannu Krosing <hannu@2ndQuadrant.com>) |
Список | pgsql-hackers |
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 > > >
В списке pgsql-hackers по дате отправления: