Thread

1. proposal: ANSI SQL 2011 syntax for named parameters

   Pavel Stehule <pavel.stehule@gmail.com> — 2012-12-28T16:22:26Z

   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
   

2. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Peter Eisentraut <peter_e@gmx.net> — 2012-12-28T21:19:57Z

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

3. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Gavin Flower <gavinflower@archidevsys.co.nz> — 2012-12-28T21:41:11Z

   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
   
   
   
   
   

4. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Pavel Stehule <pavel.stehule@gmail.com> — 2012-12-29T08:14:23Z

   2012/12/28 Gavin Flower <GavinFlower@archidevsys.co.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
   >
   >
   >
   >
   
   
   

5. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Robert Haas <robertmhaas@gmail.com> — 2013-01-02T22:51:55Z

   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.
   
   -- 
   Robert Haas
   EnterpriseDB: http://www.enterprisedb.com
   The Enterprise PostgreSQL Company
   
   
   

6. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-01-03T07:55:03Z

   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
   
   
   

7. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-02-04T08:55:20Z

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

8. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Gavin Flower <gavinflower@archidevsys.co.nz> — 2013-02-04T17:34:04Z

   On 04/02/13 21:55, Pavel Stehule wrote:
   > 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.
   >>
   > 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
   

9. Re: proposal: ANSI SQL 2011 syntax for named parameters

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-02-04T17:51:15Z

   2013/2/4 Gavin Flower <GavinFlower@archidevsys.co.nz>:
   > On 04/02/13 21:55, Pavel Stehule wrote:
   >
   > 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.
   >
   > 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
   
   
   

10. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Simon Riggs <simon@2ndquadrant.com> — 2013-02-04T18:06:51Z

    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.
    
    -- 
     Simon Riggs                   http://www.2ndQuadrant.com/
     PostgreSQL Development, 24x7 Support, Training & Services
    
    
    

11. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Robert Haas <robertmhaas@gmail.com> — 2013-02-04T19:53:07Z

    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
    
    
    

12. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Simon Riggs <simon@2ndquadrant.com> — 2013-02-04T20:32:58Z

    On 4 February 2013 19:53, Robert Haas <robertmhaas@gmail.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
    
    
    

13. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-02-05T06:50:26Z

    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
    
    
    

14. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Robert Haas <robertmhaas@gmail.com> — 2013-02-06T17:43:18Z

    On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
    > On 4 February 2013 19:53, Robert Haas <robertmhaas@gmail.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
    
    
    

15. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Simon Riggs <simon@2ndquadrant.com> — 2013-02-06T18:06:36Z

    On 6 February 2013 17:43, Robert Haas <robertmhaas@gmail.com> wrote:
    > On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
    >> On 4 February 2013 19:53, Robert Haas <robertmhaas@gmail.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
    
    
    

16. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Robert Haas <robertmhaas@gmail.com> — 2013-02-06T20:31:49Z

    On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
    > On 6 February 2013 17:43, Robert Haas <robertmhaas@gmail.com> wrote:
    >> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
    >>> On 4 February 2013 19:53, Robert Haas <robertmhaas@gmail.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
    
    
    

17. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Simon Riggs <simon@2ndquadrant.com> — 2013-02-07T11:42:59Z

    On 6 February 2013 20:31, Robert Haas <robertmhaas@gmail.com> wrote:
    > On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
    >> On 6 February 2013 17:43, Robert Haas <robertmhaas@gmail.com> wrote:
    >>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
    >>>> On 4 February 2013 19:53, Robert Haas <robertmhaas@gmail.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
    
    
    

18. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Robert Haas <robertmhaas@gmail.com> — 2013-02-07T11:49:32Z

    On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs <simon@2ndquadrant.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
    
    
    

19. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Dimitri Fontaine <dimitri@2ndquadrant.fr> — 2013-02-07T16:32:04Z

    Robert Haas <robertmhaas@gmail.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
    
    
    

20. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Tom Lane <tgl@sss.pgh.pa.us> — 2013-02-07T17:06:30Z

    Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
    > Robert Haas <robertmhaas@gmail.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
    
    
    

21. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Dimitri Fontaine <dimitri@2ndquadrant.fr> — 2013-02-07T17:21:16Z

    Tom Lane <tgl@sss.pgh.pa.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
    
    
    

22. Re: proposal: ANSI SQL 2011 syntax for named parameters

    Tom Lane <tgl@sss.pgh.pa.us> — 2013-02-08T05:05:12Z

    Robert Haas <robertmhaas@gmail.com> writes:
    > On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs <simon@2ndquadrant.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