Re: proposal sql: labeled function params
От | Robert Haas |
---|---|
Тема | Re: proposal sql: labeled function params |
Дата | |
Msg-id | 603c8f070808171707lede45d8te5e92e9cce3941a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal sql: labeled function params (Hannu Krosing <hannu@2ndQuadrant.com>) |
Список | pgsql-hackers |
> uups, completely forgot dual use of = for both assignment and > comparison. > > Maybe we can do without any "keyword arguments" or "labeled function > params" if we define a way to construct records in-place. That sounds a lot cleaner to me. > something like > RECORD( 'Zdanek'::text AS name, 22::int AS age); -- like SELECT > or > RECORD( name 'Zdanek'::text, age 22::int); -- like CREATE TABLE/TYPE > or > RECORD(name, age) .... from sometable; -- get values & types from table In most cases, you can just do this using SELECT without the need for any special syntax. For example: SELECT json(p) FROM person p; SELECT json(p) FROM (SELECT first_name, last_name FROM person) p; The only problem is that this doesn't work if you try to put the select into the attribute list: SELECT json(select first_name, last_name) FROM person p; ERROR: syntax error at or near "select" SELECT json((select first_name, last_name)) FROM person p; ERROR: subquery must return only one column Unfortunately this is a pretty common situation, because you might easily want to do: SELECT json((select first_name, last_name)), age FROM person p; ...and you are out of luck. I'm not sure whether the ROW() syntax could possibly be extended to address this problem. It doesn't seem to help in its present form. > Then we could pass these records to any PL for processing with minimal > confusion to programmer, and without introducing new concepts like > "variadic argument position labels" Amen. ...Robert
В списке pgsql-hackers по дате отправления: