Re: WIP: default values for function parameters - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: WIP: default values for function parameters
Date
Msg-id 87y6ylsaof.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: WIP: default values for function parameters  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: WIP: default values for function parameters  ("David E. Wheeler" <david@kineticode.com>)
Re: WIP: default values for function parameters  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
"Pavel Stehule" <pavel.stehule@gmail.com> writes:

> 2008/12/12 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
>
>> We could do it the other way round:
>>
>> SELECT foo( 'ick' AS bar, 'ack' AS baz);

I always assumed we were talking about it this way. Everywhere else in SQL AS
is followed by the labels, not the values.

> I discussed about this form with Tom.
>
> I thing so following should be readable:
>
> name: [ optional => ] value
>
>   SELECT foo( bar: 'ick', baz: 'ack' );
>   SELECT foo( bar: => 'ick', baz: => 'ack' );
>
> or
>
>   SELECT foo( bar: = 'ick', baz: = 'ack' );
>
> reason for optional using of "=>" is too thin char ":", so =>
> optically boost the colon.

These don't solve anything. There's nothing stopping you from defining a unary
prefix operator => or =

In any case this is all weird. SQL isn't C and doesn't have random bits of
punctuation involved in syntax. It uses whole words for just about everything.
Anything you do using punctuation characters is going to look out of place.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: benchmarking the query planner
Next
From: KaiGai Kohei
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)