Thread: 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
Attachment
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 :=.
<div class="moz-cite-prefix">On 29/12/12 10:19, Peter Eisentraut wrote:<br /></div><blockquote cite="mid:50DE0CFD.6060508@gmx.net"type="cite"><pre wrap="">On 12/28/12 11:22 AM, Pavel Stehule wrote: </pre><blockquote type="cite"><pre wrap="">I am not sure, but maybe is time to introduce ANSI SQL syntax for functions' named parameters It is defined in ANSI SQL 2011 CALL P (B => 1, A => 2) instead PostgreSQL syntax CALL ( B := 1, A := 2) </pre></blockquote><pre wrap=""> I agree it's probably time. </pre><blockquote type="cite"><pre wrap="">* should we support both - probably yes </pre></blockquote><pre wrap=""> yes </pre><blockquote type="cite"><pre wrap="">* how long time we will support pg syntax? - 2..5..ever years * when we mark pg syntax as obsolete? * when we remove pg syntax? </pre></blockquote><pre wrap=""> 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 :=. </pre></blockquote><font size="-1">To be honest I prefer </font><b>:=</b> as it looks neater than <b>=></b>, in part becauseI first saw that notation when I was learning ALGOL 60 and liked the justification they gave in the manual. <br /><br/> In fact I find <b>=></b> ugly and counter intuitive as I keep having the feeling that it points the wrong way,because <b>A => 2</b> suggests to me that you are setting '2' to the value of 'A' which is plain daft!<br /><br />I am sure there are worse standardisation formats - but for some reason, I find this one disproportionately irritating! :-)<br /><br /> So I would much prefer to keep the old format, if at all possible.<br /><br /><br /> Cheers,<br/> Gavin<br /><br /><br /><br /><br />
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 > > > >
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
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
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
<div class="moz-cite-prefix">On 04/02/13 21:55, Pavel Stehule wrote:<br /></div><blockquote cite="mid:CAFj8pRBd60BxNXN+wnRG8uYzXEC_hFzXQERc3FdUqUXEEt1vpA@mail.gmail.com"type="cite"><pre wrap="">2013/1/2 Robert Haas<a class="moz-txt-link-rfc2396E" href="mailto:robertmhaas@gmail.com"><robertmhaas@gmail.com></a>: </pre><blockquote type="cite"><pre wrap="">On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule <a class="moz-txt-link-rfc2396E"href="mailto:pavel.stehule@gmail.com"><pavel.stehule@gmail.com></a> wrote: </pre><blockquote type="cite"><pre wrap="">I am not sure, but maybe is time to introduce ANSI SQL syntax for functions' named parameters It is defined in ANSI SQL 2011 CALL P (B => 1, A => 2) instead PostgreSQL syntax CALL ( B := 1, A := 2) </pre></blockquote><pre wrap=""> Keep in mind that, as recently as PostgreSQL 9.1, we shipped hstore with a =>(text, text) operator. That operator was deprecated in 9.0, but it wasn't actually removed until PostgreSQL 9.2. Whenever we do this, it's going to break things for anyone who hasn't yet upgraded from hstore v1.0 to hstore v1.1. So I would prefer to wait one more release. That way, anyone who does an upgrade, say, every other major release cycle should have a reasonably clean upgrade path. I realize that the 4+-year journey toward allowing => rather than := probably seems tedious to many people by now, but I think the cautious path we've taken is entirely warranted. As much as I want us to be standards-compliant in this area, I also want us to not break any more user applications than necessary along the way. Incidentally, I think there are two changes here which should be considered independently. One, allowing => rather than := for specifying named parameters. And two, adding a statement called CALL that can be used to invoke a function. Maybe those are both good ideas and maybe they aren't, but they're independent. </pre></blockquote><pre wrap=""> can I recapitulate a plan? * enabling '=>' in 9.4 * we will support ':=' too What we can (or have to) do now? Regards Pavel </pre><blockquote type="cite"><pre wrap="">-- Robert Haas EnterpriseDB: <a class="moz-txt-link-freetext" href="http://www.enterprisedb.com">http://www.enterprisedb.com</a> The Enterprise PostgreSQL Company </pre></blockquote><pre wrap=""> </pre></blockquote><font size="-1">I prefer ':=', as I like the ALGOL justification of it.<br /><br /> But I won't even <fontsize="-1"><font size="-1">threaten</font> to </font>hold my breath if I'm not allowed to use ':='! :-)<br /><br /><br/><font size="-1">Cheers,<br /><font size="-1">Gavin</font><br /></font></font>
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
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
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
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
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
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
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
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
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
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
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
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
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
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