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 по дате отправления:

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Re: multiple CREATE FUNCTION AS items for PLs
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Proposal: Store "timestamptz" of database creation on "pg_database"