2014-10-22 18:35 GMT+02:00 Merlin Moncure <mmonc...@gmail.com>:
> On Wed, Oct 22, 2014 at 11:21 AM, Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
> > Hi
> >
> > with new functions row_to_json(b), there is more often usage of ROW
> > constructor. Using names in fields is relative difficult. Because ROW has
> > special clause in parser, I am thinking so we can enable labeling inside
> ROW
> > constructor
> >
> > so instead currently supported:
> >
> > select row_to_json(r) from (select 10 as a, 20 as b) r;
> >
> > users can to write:
> >
> > select row_to_json(row(10 as a,20 as b));
> >
> > labeling will be enabled "only" inside ROW constructor. I don't propose
> > enable it everywhere.
> >
> > What do you think about it?
>
> It's a neat idea -- maybe a better alternative to what I was thinking
> here:
> http://postgresql.1045698.n5.nabble.com/Support-UPDATE-table-SET-tp5823073p5823944.html
>
> Some questions:
> *) What would the parser transformation resolve to
>
row: ROW '(' expr_list ')' { $$
= $3; }
| ROW '('
')' { $$ = NIL; }
| '(' expr_list ',' a_expr ')' {
$$ = lappend($2, $4); }
;
we can replace a expr_list by target_list. I know only so it doesn't
enforce a problems with gramatic - bison doesn't raise any warning.
*) Are we ok with SQL standard
>
SQL standard doesn't think named attributes in row - so it is out of range
ANSI. But it is not in conflict with standard. "AS name" is used more in
SQL/MM, SQL/XML -- and function named parameters has different syntax
"parameter_name <= value" - I checked it against SQL99.
> *) Do you think this (or some similar variant) would work?
>
> select row_to_json(row(foo.*)) from foo;
>
It looks like independent feature and can work too - it is more natural for
user.
>
> merlin
>
