Re: proposal: ANSI SQL 2011 syntax for named parameters

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: proposal: ANSI SQL 2011 syntax for named parameters
Date: 2013-02-04 17:34:04
Message-ID: 510FF10C.20809@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/02/13 21:55, Pavel Stehule wrote:
> 2013/1/2 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>> I am not sure, but maybe is time to introduce ANSI SQL syntax for
>>> functions' named parameters
>>>
>>> It is defined in ANSI SQL 2011
>>>
>>> CALL P (B => 1, A => 2)
>>>
>>> instead PostgreSQL syntax CALL ( B := 1, A := 2)
>> Keep in mind that, as recently as PostgreSQL 9.1, we shipped hstore
>> with a =>(text, text) operator. That operator was deprecated in 9.0,
>> but it wasn't actually removed until PostgreSQL 9.2. Whenever we do
>> this, it's going to break things for anyone who hasn't yet upgraded
>> from hstore v1.0 to hstore v1.1. So I would prefer to wait one more
>> release. That way, anyone who does an upgrade, say, every other major
>> release cycle should have a reasonably clean upgrade path.
>>
>> I realize that the 4+-year journey toward allowing => rather than :=
>> probably seems tedious to many people by now, but I think the cautious
>> path we've taken is entirely warranted. As much as I want us to be
>> standards-compliant in this area, I also want us to not break any more
>> user applications than necessary along the way.
>>
>> Incidentally, I think there are two changes here which should be
>> considered independently. One, allowing => rather than := for
>> specifying named parameters. And two, adding a statement called CALL
>> that can be used to invoke a function. Maybe those are both good
>> ideas and maybe they aren't, but they're independent.
>>
> can I recapitulate a plan?
>
> * enabling '=>' in 9.4
> * we will support ':=' too
>
> What we can (or have to) do now?
>
> Regards
>
> Pavel
>
>
>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
I prefer ':=', as I like the ALGOL justification of it.

But I won't even threaten to hold my breath if I'm not allowed to use
':='! :-)

Cheers,
Gavin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2013-02-04 17:45:58 Re: sepgsql and materialized views
Previous Message Andres Freund 2013-02-04 17:29:15 Re: GetOldestXmin going backwards is dangerous after all