Re: proposal sql: labeled function params

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal sql: labeled function params
Date: 2008-08-14 21:05:56
Message-ID: 1218747956.14869.20.camel@huvostro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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

"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.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-08-14 21:33:04 Re: gsoc, oprrest function for text search take 2
Previous Message Andrew Satori 2008-08-14 20:33:59 API for Managing pg_hba and postgresql.conf