Re: proposal sql: labeled function params - Mailing list pgsql-hackers
From | Hannu Krosing |
---|---|
Subject | Re: proposal sql: labeled function params |
Date | |
Msg-id | 1218747956.14869.20.camel@huvostro Whole thread Raw |
In response to | proposal sql: labeled function params ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Responses |
Re: proposal sql: labeled function params
Re: proposal sql: labeled function params |
List | pgsql-hackers |
On Thu, 2008-08-14 at 11:56 +0200, Pavel Stehule wrote: > Hello > > I propose enhance current syntax that allows to specify label for any > function parameter: > > fcename(expr [as label], ...) > fcename(colname, ...) also fcename(localvar, ...) if called from another function ? How is this supposed to interact with argument names ? > I would to allow same behave of custom functions like xmlforest function: > postgres=# select xmlforest(a) from foo; > xmlforest > ----------- > <a>10</a> > (1 row) > > postgres=# select xmlforest(a as b) from foo; > xmlforest > ----------- > <b>10</b> > (1 row) Why not just have two arguments to xmlforest(label text,value text) like this: "select xmlforest('b', a) from foo" ? > Actually I am not sure what is best way for PL languages for acces to > these info. Using some system variables needed new column in pg_proc, > because collecting these needs some time and in 99% cases we don't > need it. Exactly, maybe it is just a bad idea in general to pass the label info into functions using some special syntax ? what is wrong with passing it in regular arguments ? I see very little gain from complicating the syntax (and function API). maybe we will some time have keyword arguments as well and then have to deal with syntax like select func(arg4=7 as 'labelfor4') > So I prefere some system function that returns labels for > outer function call. Like > > -- test > create function getlabels() returns varchar[] as $$select '{name, > age}'::varchar[]$$ language sql immutable; > > create or replace function json(variadic varchar[]) > returns varchar as $$ > select '[' || array_to_string( > array( > select (getlabels())[i]|| ':' || $1[i] > from generate_subscripts($1,1) g(i)) > ,',') || ']' > $$ language sql immutable strict; just write the function to take arguments as pairs (value, 'label', ...) select json('Zdenek', 'name','30', 'age'); select json(name, 'name', age, 'age') from person; > postgres=# select json('Zdenek' as name,'30' as age); > json > ---------------------- > [name:Zdenek,age:30] > (1 row) > > postgres=# select json(name, age) from person; > json > ---------------------- > [name:Zdenek,age:30] > (1 row) why special-case table fields ? what if you wanted to rename any table fields ? > There are two possibilities > a) collect labels in parse time > b) collect labels in executor time > > @a needs info in pg_proc, but it is simpler, @b is little bit > difficult, but doesn't need any changes in system catalog. I thinking > about b now. > > Necessary changes: > ================= > labels are searched in parse tree fcinfo->flinfo->fn_expr. I need > insert label into parse tree, so I it needs special node > labeled_param, For getting column reference I need to put current > exprstate to fcinfo. Function getlabels() should take code from > ExecEvalVar function. > > Any notes, ideas? To me, this whole thing feels backwards - in described cases "labels" seem to be just like any other data and I don't think it justifies a special syntax. --------------- Hannu
pgsql-hackers by date: