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

From Pavel Stehule
Subject Re: proposal: ANSI SQL 2011 syntax for named parameters
Date
Msg-id CAFj8pRCvtSc8cuAV0KOdQWY5-7OB_pC+jYZpQ3hB7ApSb2AZtA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: ANSI SQL 2011 syntax for named parameters  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
2013/2/4 Robert Haas <robertmhaas@gmail.com>:
> 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.

| 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



pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: Re: get_progname() should not be const char *?
Next
From: Pavel Stehule
Date:
Subject: Re: json api WIP patch