Re: proposal: ANSI SQL 2011 syntax for named parameters

Hello

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)

Patch is very simple, but there are lot of questions about support
previous syntax.

* should we support both - probably yes

* how long time we will support pg syntax? - 2..5..ever years

* when we mark pg syntax as obsolete?

* when we remove pg syntax?

Regards

Pavel

On 12/28/12 11:22 AM, Pavel Stehule 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)

I agree it's probably time.

> * should we support both - probably yes

yes

> * how long time we will support pg syntax? - 2..5..ever years
>
> * when we mark pg syntax as obsolete?
>
> * when we remove pg syntax?

The := syntax was introduced in 9.0, so it is by now well entrenched. I
don't think we should remove it at all any time soon.

As for documentation, just state how it is. The standard syntax is =>,
but because of $various_issues, older versions only support :=.

On 29/12/12 10:19, Peter Eisentraut wrote:
> On 12/28/12 11:22 AM, Pavel Stehule 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)
> I agree it's probably time.
>
>> * should we support both - probably yes
> yes
>
>> * how long time we will support pg syntax? - 2..5..ever years
>>
>> * when we mark pg syntax as obsolete?
>>
>> * when we remove pg syntax?
> The := syntax was introduced in 9.0, so it is by now well entrenched. I
> don't think we should remove it at all any time soon.
>
> As for documentation, just state how it is. The standard syntax is =>,
> but because of $various_issues, older versions only support :=.
>
>
>
To be honest I prefer *:=* as it looks neater than *=>*, in part because
I first saw that notation when I was learning ALGOL 60 and liked the
justification they gave in the manual.

In fact I find *=>* ugly and counter intuitive as I keep having the
feeling that it points the wrong way, because *A => 2* suggests to me
that you are setting '2' to the value of 'A' which is plain daft!

I am sure there are worse standardisation formats - but for some reason,
I find this one disproportionately irritating! :-)

So I would much prefer to keep the old format, if at all possible.

Cheers,
Gavin

2012/12/28 Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>:
> On 29/12/12 10:19, Peter Eisentraut wrote:
>
> On 12/28/12 11:22 AM, Pavel Stehule 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)
>
> I agree it's probably time.
>
> * should we support both - probably yes
>
> yes
>
> * how long time we will support pg syntax? - 2..5..ever years
>
> * when we mark pg syntax as obsolete?
>
> * when we remove pg syntax?
>
> The := syntax was introduced in 9.0, so it is by now well entrenched. I
> don't think we should remove it at all any time soon.
>
> As for documentation, just state how it is. The standard syntax is =>,
> but because of $various_issues, older versions only support :=.
>
>
>
> To be honest I prefer := as it looks neater than =>, in part because I first
> saw that notation when I was learning ALGOL 60 and liked the justification
> they gave in the manual.
>
> In fact I find => ugly and counter intuitive as I keep having the feeling
> that it points the wrong way, because A => 2 suggests to me that you are
> setting '2' to the value of 'A' which is plain daft!

It doesn't mean ASSIGN but maybe ASSOCIATE - for me the best natural
is syntax, that we don't use (or is used less in SQL/XML) with keyword
AS

supported syntax -- A := 2; ANSI SQL -- A => 2; and my natural (but it
subjective) -- 2 AS A

I don't know a original motivation for using symbol '=>' - but is
widely used for associative arrays in Perl like languages.

And if I can go to deeper history - it is used for named parameters in
ADA language http://en.wikibooks.org/wiki/Ada_Programming/Subprograms

Regards

Pavel

>
> I am sure there are worse standardisation formats - but for some reason, I
> find this one disproportionately irritating! :-)
>
> So I would much prefer to keep the old format, if at all possible.
>
>
> Cheers,
> Gavin
>
>
>
>

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.

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

Hello

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.

Regards

Pavel

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

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.
>

can I recapitulate a plan?

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

What we can (or have to) do now?

Regards

Pavel

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

On 04/02/13 21:55, Pavel Stehule wrote:
> 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.
>>
> can I recapitulate a plan?
>
> * enabling '=>' in 9.4
> * we will support ':=' too
>
> What we can (or have to) do now?
>
> Regards
>
> Pavel
>
>
>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
I prefer ':=', as I like the ALGOL justification of it.

But I won't even threaten to hold my breath if I'm not allowed to use
':='! :-)

Cheers,
Gavin

2013/2/4 Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>:
> On 04/02/13 21:55, Pavel Stehule wrote:
>
> 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.
>
> can I recapitulate a plan?
>
> * enabling '=>' in 9.4
> * we will support ':=' too
>
> What we can (or have to) do now?
>
> Regards
>
> Pavel
>
>
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> I prefer ':=', as I like the ALGOL justification of it.

:= is not in ANSI SQL, so we are sure about '=>' (ADA wins :))

':=' can be supported as secondary form (and I don't plan remove it)

A timing is question now.

Regards

Pavel

>
> But I won't even threaten to hold my breath if I'm not allowed to use ':='!
> :-)
>
>
> Cheers,
> Gavin

On 2 January 2013 22:51, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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 don't see why waiting 1 year makes this situation any better. We
just make upgrading to hstore 1.1 a prerequisite and we're done.

I doubt there are many people using hstore who haven't upgraded, and
fewer still that will upgrade yet can't follow simple instructions on
prerequisites. While hstore is reasonably popular, users are still in
the minority.

You can always override the operators using a different search_path if
you still see problems there.

We need to find ways forwards rather than block progress because of
obscure issues.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 2 January 2013 22:51, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> 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 don't see why waiting 1 year makes this situation any better. We
> just make upgrading to hstore 1.1 a prerequisite and we're done.
>
> I doubt there are many people using hstore who haven't upgraded, and
> fewer still that will upgrade yet can't follow simple instructions on
> prerequisites. While hstore is reasonably popular, users are still in
> the minority.
>
> You can always override the operators using a different search_path if
> you still see problems there.
>
> We need to find ways forwards rather than block progress because of
> obscure issues.

This seems pretty close to an accusation of bad faith, which I don't
believe to be present. Right now there is one and only one release in
the field that contains hstore 1.1. If we go ahead and prohibit => as
an operator name now, we're going to require everyone who is on 9.1
and uses hstore and wants to get to 9.3 to either (a) first upgrade to
9.2, then update hstore, then upgrade to 9.3; or (b) dig the
hstore-1.1 update out of a future release, apply it to an earlier
release on which it did not ship, and then upgrade. If they're
actually *using* the => operator (rather than just having it in the
DB), they'll also need to rewrite their application before doing any
of that.

Perhaps the users that you support won't mind that, but the users I
support will. In fact, they're likely going to mind it even if we
have two releases where either version of hstore will work, but at
least it will ameliorate the problem somewhat.

I find your attitude toward backward compatibility to be astonishingly
inconsistent. We haven't made any progress on overhauling
recovery.conf in two years because you've steadfastly stonewalled any
forward progress on backwards-compatibility grounds, even though a
change there can't possible break any working PostgreSQL
*application*, only the admin tools. But now, on this change and on a
few others, which actually will break applications, you want to push
it forward faster. That seems completely backwards to me. In my
experience, it is far easier to get people to adjust their admin
scripts (which are usually controlled by the same team responsible for
the database upgrade anyway) than to get them to fix their
applications (which are usually written by a different team over which
the DBAs have no real control).

We've had customers postpone upgrades for *years* because of issues
like this. Labeling it as obscure suggests that it is unimportant or
should be dismissed, a conclusion with which I respectfully disagree.

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

On 4 February 2013 19:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> This seems pretty close to an accusation of bad faith, which I don't
> believe to be present.

Robert, this is not an accusation of bad faith, just an observation
that we can move forwards more quickly.

I understand completely why you wish to make slow changes, I just
don't believe it is warranted in this case. I'm not sure how or why
that becomes some kind of accusation against you personally.

In this case, and others, moving forwards quickly can be achieved at
the same time as backwards compatibility with some thought and
documentation.

> I find your attitude toward backward compatibility to be astonishingly
> inconsistent. We haven't made any progress on overhauling
> recovery.conf in two years because you've steadfastly stonewalled any
> forward progress on backwards-compatibility grounds, even though a
> change there can't possible break any working PostgreSQL
> *application*, only the admin tools.

I stonewalled nothing; what exactly do you think I hoped to gain by
such actions? In fact, I repeatedly encouraged change and showed how
we could have both backwards compatibility and progress. Any lack of
progress is not a result of my request for backwards compatibility,
made in the interests of avoiding data loss and very broken
applications.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2013/2/4 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 2 January 2013 22:51, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> 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 don't see why waiting 1 year makes this situation any better. We
>> just make upgrading to hstore 1.1 a prerequisite and we're done.
>>
>> I doubt there are many people using hstore who haven't upgraded, and
>> fewer still that will upgrade yet can't follow simple instructions on
>> prerequisites. While hstore is reasonably popular, users are still in
>> the minority.
>>
>> You can always override the operators using a different search_path if
>> you still see problems there.
>>
>> We need to find ways forwards rather than block progress because of
>> obscure issues.
>
> This seems pretty close to an accusation of bad faith, which I don't
> believe to be present. Right now there is one and only one release in
> the field that contains hstore 1.1. If we go ahead and prohibit => as
> an operator name now, we're going to require everyone who is on 9.1
> and uses hstore and wants to get to 9.3 to either (a) first upgrade to
> 9.2, then update hstore, then upgrade to 9.3; or (b) dig the
> hstore-1.1 update out of a future release, apply it to an earlier
> release on which it did not ship, and then upgrade. If they're
> actually *using* the => operator (rather than just having it in the
> DB), they'll also need to rewrite their application before doing any
> of that.
>
> Perhaps the users that you support won't mind that, but the users I
> support will. In fact, they're likely going to mind it even if we
> have two releases where either version of hstore will work, but at
> least it will ameliorate the problem somewhat.
>
> I find your attitude toward backward compatibility to be astonishingly
> inconsistent. We haven't made any progress on overhauling
> recovery.conf in two years because you've steadfastly stonewalled any
> forward progress on backwards-compatibility grounds, even though a
> change there can't possible break any working PostgreSQL
> *application*, only the admin tools. But now, on this change and on a
> few others, which actually will break applications, you want to push
> it forward faster. That seems completely backwards to me. In my
> experience, it is far easier to get people to adjust their admin
> scripts (which are usually controlled by the same team responsible for
> the database upgrade anyway) than to get them to fix their
> applications (which are usually written by a different team over which
> the DBAs have no real control).
>
> We've had customers postpone upgrades for *years* because of issues
> like this. Labeling it as obscure suggests that it is unimportant or
> should be dismissed, a conclusion with which I respectfully disagree.

| know so GUC is not popular but we can introduce new syntax controlled by GUC.

Probably there are not simple best solution. People that use hstore
will prefer compatibility and slower progress, people that wrote more
stored procedures will prefer faster progress - because will write lot
of code with possible obsolete (in future) syntax. GUC can introduce
this feature early - and don't create or don't solve any problems that
we (or users) have to solve in following versions.

Regards

Pavel

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

On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 4 February 2013 19:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> This seems pretty close to an accusation of bad faith, which I don't
>> believe to be present.
>
> Robert, this is not an accusation of bad faith, just an observation
> that we can move forwards more quickly.

It's your opinion, to which you are certainly entitled, but it is not
an observation of an objective fact.

>> I find your attitude toward backward compatibility to be astonishingly
>> inconsistent. We haven't made any progress on overhauling
>> recovery.conf in two years because you've steadfastly stonewalled any
>> forward progress on backwards-compatibility grounds, even though a
>> change there can't possible break any working PostgreSQL
>> *application*, only the admin tools.
>
> I stonewalled nothing; what exactly do you think I hoped to gain by
> such actions? In fact, I repeatedly encouraged change and showed how
> we could have both backwards compatibility and progress. Any lack of
> progress is not a result of my request for backwards compatibility,
> made in the interests of avoiding data loss and very broken
> applications.

I don't agree with that characterization of what happened. There was
a patch that basically everyone except you agreed on last year around
this time, and neither it nor anything else has been committed. The
issue here is rather complicated because there are a lot of subtly
different things that could be done, and I think saying that you
"showed how we could have both backward compatibility and progress"
sweeps a significant amount of meaningful detail under the rug. As I
recall, there were meaningful objections to your counter-proposal, you
didn't agree with those objections, and that's where we got stuck.
What we need on that issue is a detailed plan that meets with general
agreement, not an assertion (without supporting detail) that you know
how to solve the problem.

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

On 6 February 2013 17:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 4 February 2013 19:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> This seems pretty close to an accusation of bad faith, which I don't
>>> believe to be present.
>>
>> Robert, this is not an accusation of bad faith, just an observation
>> that we can move forwards more quickly.
>
> It's your opinion, to which you are certainly entitled, but it is not
> an observation of an objective fact.

And what? You expressed an opinion, as did I.

I repeat: I don't see why waiting a year changes anything here. Can
you please explain why the situation is improved by waiting a year?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 6 February 2013 17:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> On 4 February 2013 19:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> This seems pretty close to an accusation of bad faith, which I don't
>>>> believe to be present.
>>>
>>> Robert, this is not an accusation of bad faith, just an observation
>>> that we can move forwards more quickly.
>>
>> It's your opinion, to which you are certainly entitled, but it is not
>> an observation of an objective fact.
>
> And what? You expressed an opinion, as did I.
>
> I repeat: I don't see why waiting a year changes anything here. Can
> you please explain why the situation is improved by waiting a year?

What was unclear or incomplete about the last two times I explained
it? Here's what I wrote the first time:

$ 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.

And here's what I wrote the second time:

$ Right now there is one and only one release in
$ the field that contains hstore 1.1. If we go ahead and prohibit => as
$ an operator name now, we're going to require everyone who is on 9.1
$ and uses hstore and wants to get to 9.3 to either (a) first upgrade to
$ 9.2, then update hstore, then upgrade to 9.3; or (b) dig the
$ hstore-1.1 update out of a future release, apply it to an earlier
$ release on which it did not ship, and then upgrade.

I don't know what to add to that.

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

On 6 February 2013 20:31, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 6 February 2013 17:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>> On 4 February 2013 19:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>>> This seems pretty close to an accusation of bad faith, which I don't
>>>>> believe to be present.
>>>>
>>>> Robert, this is not an accusation of bad faith, just an observation
>>>> that we can move forwards more quickly.
>>>
>>> It's your opinion, to which you are certainly entitled, but it is not
>>> an observation of an objective fact.
>>
>> And what? You expressed an opinion, as did I.
>>
>> I repeat: I don't see why waiting a year changes anything here. Can
>> you please explain why the situation is improved by waiting a year?
>
> What was unclear or incomplete about the last two times I explained
> it? Here's what I wrote the first time:
>
> $ 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.
>
> And here's what I wrote the second time:
>
> $ Right now there is one and only one release in
> $ the field that contains hstore 1.1. If we go ahead and prohibit => as
> $ an operator name now, we're going to require everyone who is on 9.1
> $ and uses hstore and wants to get to 9.3 to either (a) first upgrade to
> $ 9.2, then update hstore, then upgrade to 9.3; or (b) dig the
> $ hstore-1.1 update out of a future release, apply it to an earlier
> $ release on which it did not ship, and then upgrade.
>
> I don't know what to add to that.

I don't see a problem with requiring that, but there are other ways also.

hstore, as well as other code, might contain a definition of the =>
operator. So the hstore situation isn't that relevant in itself.

There is potentially code out there that currently runs on PostgreSQL
that uses =>. There is also potentially code out there that could run
on Postgres if we allow the => standard syntax. There is also a
conflict in that we are continuing to encourage the development of
non-standard code because we aren't supporting the standard yet. So
there is a conflict.

IMO the way to resolve that conflict is with a behaviour parameter to
allow people to choose, rather than be forced to wait a year because
some people still run an old version of an add-on package. A good way
to do that would be to have a sql_standard = postgres | 2011 etc so we
can tick the box in having a sql standard flagger as well.

I believe the same issue exists with the -> operator, which is also
part of the SQL standard on "reference types".

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> IMO the way to resolve that conflict is with a behaviour parameter to
> allow people to choose, rather than be forced to wait a year because
> some people still run an old version of an add-on package. A good way
> to do that would be to have a sql_standard = postgres | 2011 etc so we
> can tick the box in having a sql standard flagger as well.

The undesirability of syntax-altering GUCs has been discussed here on
many occasions.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> $ Right now there is one and only one release in
> $ the field that contains hstore 1.1. If we go ahead and prohibit => as
> $ an operator name now, we're going to require everyone who is on 9.1
> $ and uses hstore and wants to get to 9.3 to either (a) first upgrade to
> $ 9.2, then update hstore, then upgrade to 9.3; or (b) dig the
> $ hstore-1.1 update out of a future release, apply it to an earlier
> $ release on which it did not ship, and then upgrade.
>
> I don't know what to add to that.

There's no technical reason that I'm aware of for hstore 1.1 not to
support all our maintained releases at the same time. That's exactly how
we do it with non-core extensions, by the way.

To make that easier to maintain, there's a patch in the queue
implementing default_major_version so that we can ship hstore--1.0.sql
and hstore--1.0--1.1.sql and still have that command just works:

CREATE EXTENSION hstore VERSION '1.1';

That support is going to ease a lot dump and support of Extensions
installed from a Template, too, so much so that I would really like to
get some reviewing about that before sending the full patch.

We've been talking about "in-core extensions" as opposed to contribs for
a while now, I think this is another angle to see things through. We
could actually maintain proper extensions the proper way.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I don't know what to add to that.

> There's no technical reason that I'm aware of for hstore 1.1 not to
> support all our maintained releases at the same time. That's exactly how
> we do it with non-core extensions, by the way.

If you're suggesting that we should back-patch hstore 1.1 into 9.1,
there might not be a technical reason why we couldn't do it, but there
are certainly project-policy reasons. Removing operators, or indeed
changing any SQL interface at all, is exactly the kind of change we do
not make in back branches.

> To make that easier to maintain, there's a patch in the queue
> implementing default_major_version so that we can ship hstore--1.0.sql
> and hstore--1.0--1.1.sql and still have that command just works:
> CREATE EXTENSION hstore VERSION '1.1';

If the argument for this patch is only to support doing something like
the above, I'd vote for rejecting it entirely.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> If you're suggesting that we should back-patch hstore 1.1 into 9.1,
> there might not be a technical reason why we couldn't do it, but there
> are certainly project-policy reasons. Removing operators, or indeed
> changing any SQL interface at all, is exactly the kind of change we do
> not make in back branches.

For core itself, it makes perfect sense. For extensions, I wonder about
the upgrade path, and if we shouldn't leave some level fo choice to the
user. Shipping the ability to upgrade to hstore 1.1 into back branches
is not the same thing as upgrading our users.

>> To make that easier to maintain, there's a patch in the queue
>> implementing default_major_version so that we can ship hstore--1.0.sql
>> and hstore--1.0--1.1.sql and still have that command just works:
>> CREATE EXTENSION hstore VERSION '1.1';
>
> If the argument for this patch is only to support doing something like
> the above, I'd vote for rejecting it entirely.

This patch allows us to ship bug and security fixes in back branches
without having to maintain both the 1.1 and the 1.2 full scripts, as
PostgreSQL will now be able to install 1.1 and upgrade to 1.2 at CREATE
EXTENSION time.

So no, this patch is not made for something like forcing incompatible
changes down the throat of our users, it's made to make the life of
extension maintainers (core included) easier.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> IMO the way to resolve that conflict is with a behaviour parameter to
>> allow people to choose, rather than be forced to wait a year because
>> some people still run an old version of an add-on package. A good way
>> to do that would be to have a sql_standard = postgres | 2011 etc so we
>> can tick the box in having a sql standard flagger as well.

> The undesirability of syntax-altering GUCs has been discussed here on
> many occasions.

Note that a GUC to change the behavior of the lexer or grammar is
particularly undesirable, for reasons noted at the top of gram.y as
well as others having to do with the behavior of plancache.c.
(Hint: it caches grammar output, not raw source text.)

We've put up with that for standard_conforming_strings because we
pretty much had to, but that doesn't mean that introducing more
such GUCs would be wise.

But regardless of those particular implementation artifacts, I think
most of us have come to the conclusion that GUCs that alter query
semantics are far more dangerous and unpleasant-to-use than they
might look.

regards, tom lane