Re: proposal: ANSI SQL 2011 syntax for named parameters

Поиск
Список
Период
Сортировка
От Gavin Flower
Тема Re: proposal: ANSI SQL 2011 syntax for named parameters
Дата
Msg-id 510FF10C.20809@archidevsys.co.nz
обсуждение исходный текст
Ответ на 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>)
Список pgsql-hackers
<div class="moz-cite-prefix">On 04/02/13 21:55, Pavel Stehule wrote:<br /></div><blockquote
cite="mid:CAFj8pRBd60BxNXN+wnRG8uYzXEC_hFzXQERc3FdUqUXEEt1vpA@mail.gmail.com"type="cite"><pre wrap="">2013/1/2 Robert
Haas<a class="moz-txt-link-rfc2396E" href="mailto:robertmhaas@gmail.com"><robertmhaas@gmail.com></a>: 
</pre><blockquote type="cite"><pre wrap="">On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule <a
class="moz-txt-link-rfc2396E"href="mailto:pavel.stehule@gmail.com"><pavel.stehule@gmail.com></a> wrote: 
</pre><blockquote type="cite"><pre wrap="">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)
</pre></blockquote><pre wrap="">
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.

</pre></blockquote><pre wrap="">
can I recapitulate a plan?

* enabling '=>' in 9.4
* we will support ':=' too

What we can (or have to) do now?

Regards

Pavel



</pre><blockquote type="cite"><pre wrap="">--
Robert Haas
EnterpriseDB: <a class="moz-txt-link-freetext" href="http://www.enterprisedb.com">http://www.enterprisedb.com</a>
The Enterprise PostgreSQL Company
</pre></blockquote><pre wrap="">

</pre></blockquote><font size="-1">I prefer ':=', as I like the ALGOL justification of it.<br /><br /> But I won't even
<fontsize="-1"><font size="-1">threaten</font> to </font>hold my breath if I'm not allowed to use ':='!  :-)<br /><br
/><br/><font size="-1">Cheers,<br /><font size="-1">Gavin</font><br /></font></font> 

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: GetOldestXmin going backwards is dangerous after all
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: sepgsql and materialized views