Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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.



> --
> Robert Haas
> EnterpriseDB:
> The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group