Re: proposal: ANSI SQL 2011 syntax for named parameters - Mailing list pgsql-hackers

On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 2 January 2013 22:51, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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 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