Re: proposal sql: labeled function params

2008/8/17 Hannu Krosing <hannu(at)2ndquadrant(dot)com>:
> On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote:
>> 2008/8/16 Decibel! <decibel(at)decibel(dot)org>:
>> > On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
>> >>>
>> >>> "value AS name", on the other hand, accomplishes the same in a more
>> >>> SQL-looking fashion with no new reserved word (since AS is already
>> >>> fully reserved).
>> >>
>> >> would it be more natural / SQL-like to use "value AS name" or "name AS
>> >> value" ?
>> >
>> >
>> > IMHO, *natural* would be name *something* value, because that's how every
>> > other language I've seen does it.
>> >
>> > SQL-like would be value AS name, but I'm not a fan of putting the value
>> > before the name. And I think value AS name will just lead to a ton of
>> > confusion.
>> >
>> > Since I think it'd be very unusual to do a => (b => c), I'd vote that we
>> > just go with =>. Anyone trying to do a => b => c should immediately question
>> > if that would work.
>>
>> I'll look on this syntax - what is really means for implementation. I
>> thing, mostly of us prefer this or similar syntax.
>
> 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)
>
> And I still don't think we need two kinds of names ("argument name" and
> "label"). I'd rather see us have the syntax for this be similar to
> python's keyword arguments, even though I'm not entirely opposed to
> automatically generating the name= part if it comes from existing name
> (variable, function argument or column name).
>

I wouldn't mix together two features - argument name (keyword
argument) and labels. Its two different features.

Regards
Pavel Stehule

> ---------------
> Hannu
>
>
>