Re: proposal: ANSI SQL 2011 syntax for named parameters

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: proposal: ANSI SQL 2011 syntax for named parameters
Дата
Msg-id CA+TgmobMsqAOUQDgs3i1ArVJ0yV8TC6L1jsuz53oeuJbDhnstQ@mail.gmail.com
обсуждение исходный текст
Ответ на proposal: ANSI SQL 2011 syntax for named parameters  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: ANSI SQL 2011 syntax for named parameters  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: proposal: ANSI SQL 2011 syntax for named parameters  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: proposal: ANSI SQL 2011 syntax for named parameters  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
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.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: multiple CREATE FUNCTION AS items for PLs
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: json api WIP patch