Re: proposal sql: labeled function params

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: proposal sql: labeled function params
Дата
Msg-id 1219015032.8075.34.camel@huvostro
обсуждение исходный текст
Ответ на Re: proposal sql: labeled function params  ("Robert Haas" <robertmhaas@gmail.com>)
Ответы Re: proposal sql: labeled function params  ("Robert Haas" <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sun, 2008-08-17 at 18:24 -0400, Robert Haas wrote:
> > Actually the most "natural" syntax to me is just f(name=value) similar
> > to how UPDATE does it. It has the added benefit of _not_ forcing us to
> > make a operator reserved (AFAIK "=" can't be used to define new ops)
> 
> The problem with this is that
> 
> SELECT foo(a = b)
>
> ...is already valid syntax.  

uups, completely forgot dual use of = for both assignment and
comparison.

> It means compare a with b and pass the
> resulting boolean to foo.  I'm almost positive that changing this
> would break all kinds of existing code (and probably create a lot of
> grammar problems too).  It's not an issue with SET because in that
> case the "name=" part of the syntax is required rather than optional.

Maybe we can do without any "keyword arguments" or "labeled function
params" if we define a way to construct records in-place.

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

?

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"

-------------
Hannu




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Steve Atkins
Дата:
Сообщение: Re: Overhauling GUCS
Следующее
От: David Fetter
Дата:
Сообщение: Re: Patch: plan invalidation vs stored procedures