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
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 |