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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: proposal sql: labeled function params  ("Pavel Stehule" <pavel.stehule@gmail.com>)
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:

Previous
From: Jan Urbański
Date:
Subject: Re: gsoc, oprrest function for text search take 2
Next
From: Andrew Satori
Date:
Subject: API for Managing pg_hba and postgresql.conf