Re: proposal: ANSI SQL 2011 syntax for named parameters
От | Pavel Stehule |
---|---|
Тема | Re: proposal: ANSI SQL 2011 syntax for named parameters |
Дата | |
Msg-id | CAFj8pRAihsWDtBoR6iVJvO-R042B4pmtjmDwezFGBxiOULHEZA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: ANSI SQL 2011 syntax for named parameters (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Hello 2013/1/2 Robert Haas <robertmhaas@gmail.com>: > On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule <pavel.stehule@gmail.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
В списке pgsql-hackers по дате отправления: