Re: proposal: ANSI SQL 2011 syntax for named parameters

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: ANSI SQL 2011 syntax for named parameters
Date: 2013-01-03 07:55:03
Message-ID: CAFj8pRAihsWDtBoR6iVJvO-R042B4pmtjmDwezFGBxiOULHEZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

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.

My recent proposal is related only to named parameters.

Statement CALL can wait to full procedure implementation. Still I hope
so we can implement some more precious transaction control and
returning free recordsets. So I don't propose a CALL statement now.

Regards

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-01-03 08:16:59 Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Previous Message Hitoshi Harada 2013-01-03 06:13:47 Re: multiple CREATE FUNCTION AS items for PLs