Thread: Re: trouble caused by change in 7.3 handling of ''
Here's what Brand X does... Knowing that backward compatibility is a large concern for customers, Microsoft incorporated the concept of compatibilitylevels into SQL Server 7.0. SQL Server 7.0 has three compatibility levels: 60 for SQL Server 6.0 databases,65 for SQL Server 6.5 databases, and 70 for SQL Server 7.0 databases. These levels let legacy databases in the7.0 environment operate as if they were running under an earlier release of the product. The system stored procedure sp_dbcmptlevel lets developers report on and change the compatibility level of their databases.For example, to set the Northwind database to level 65 compatibility, execute the following command: sp_dbcmptlevel [Northwind], 65 Ian Harding Programmer/Analyst II Tacoma-Pierce County Health Department iharding@tpchd.org (253) 798-3549 >>> "scott.marlowe" <scott.marlowe@ihs.com> 12/19/02 01:41PM >>> On Thu, 19 Dec 2002, Barry Lind wrote: > And given one report of a problem, I think that was the correct > response. I don't think it is wise to add a GUC parameter for every > change that impacts one person/one app. However if multiple people had > reported the same problem and the impact of the change was clearly > understood to negatively impact a large number of users then I am sure a > GUC parameter would have been added a while ago. > > The point I was trying to make is that there were probably a hundred > changes between 7.2 and 7.3 that could have impacted apps, some > intentional changes, others not (and it wouldn't make sense to add > parameters for all of them). Deciding which of these have a significant > impact on existing apps is part of what the beta period is for. The > more people that test their apps during the beta period the better > change we won't have issues like this in the future. So, and this is just theorizing, what about having every change that affects parsing syntacitcally, especially changes like this, be tracked and handled with a single compatibility GUC var like revert_prev_syntax that is only around for one version, defaults to off, and handles all the new versus old syntax. That way, when there's a new release, say 7.4 from 7.3, you can just strip out all the code marked as being turned on by this one GUC and move on with a new empty spot for revert_prev_syntax. Of course, then you might have a problem where reverting to old syntax takes away a feature someone wants in one area while removing a problem in another, but, if you need to revert to the previous versions syntax, then you probably aren't too worried about whether or not you have every single shiny new feature... Just a bit of a ramble. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
A compatibily flag in postgresql.conf for the previous release is interesting. One problem is that only some items can be made compatibable, and once you set it, you get all the backward compatibility stuff, rather than being able to pick the one you want. It is an interesting idea, but ultimately, it would be better if we found the items that would cause problems and add individual postgresql.conf params for those, to exist for one release. --------------------------------------------------------------------------- Ian Harding wrote: > Here's what Brand X does... > > Knowing that backward compatibility is a large concern for customers, Microsoft incorporated the concept of compatibilitylevels into SQL Server 7.0. SQL Server 7.0 has three compatibility levels: 60 for SQL Server 6.0 databases,65 for SQL Server 6.5 databases, and 70 for SQL Server 7.0 databases. These levels let legacy databases in the7.0 environment operate as if they were running under an earlier release of the product. > > The system stored procedure sp_dbcmptlevel lets developers report on and change the compatibility level of their databases.For example, to set the Northwind database to level 65 compatibility, execute the following command: > > sp_dbcmptlevel [Northwind], 65 > > > > Ian Harding > Programmer/Analyst II > Tacoma-Pierce County Health Department > iharding@tpchd.org > (253) 798-3549 > > >>> "scott.marlowe" <scott.marlowe@ihs.com> 12/19/02 01:41PM >>> > On Thu, 19 Dec 2002, Barry Lind wrote: > > > And given one report of a problem, I think that was the correct > > response. I don't think it is wise to add a GUC parameter for every > > change that impacts one person/one app. However if multiple people had > > reported the same problem and the impact of the change was clearly > > understood to negatively impact a large number of users then I am sure a > > GUC parameter would have been added a while ago. > > > > The point I was trying to make is that there were probably a hundred > > changes between 7.2 and 7.3 that could have impacted apps, some > > intentional changes, others not (and it wouldn't make sense to add > > parameters for all of them). Deciding which of these have a significant > > impact on existing apps is part of what the beta period is for. The > > more people that test their apps during the beta period the better > > change we won't have issues like this in the future. > > So, and this is just theorizing, what about having every change that > affects parsing syntacitcally, especially changes like this, be tracked > and handled with a single compatibility GUC var like revert_prev_syntax > that is only around for one version, defaults to off, and handles all the > new versus old syntax. > > That way, when there's a new release, say 7.4 from 7.3, you can just strip > out all the code marked as being turned on by this one GUC and move on > with a new empty spot for revert_prev_syntax. > > Of course, then you might have a problem where reverting to old syntax > takes away a feature someone wants in one area while removing a problem in > another, but, if you need to revert to the previous versions syntax, then > you probably aren't too worried about whether or not you have every single > shiny new feature... > > Just a bit of a ramble. > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I have another interesting idea. What if we create a postgresql.conf param called prev_compatible that exists in every release. We default it to false/0. If it always exists, we can add features under its control even in minor releases. Most interesting would be to have it be an int and make a bitmask for up to 32 features that could be made backward compatible to the previous release. This would give us an option in future releases. --------------------------------------------------------------------------- Ian Harding wrote: > Here's what Brand X does... > > Knowing that backward compatibility is a large concern for customers, Microsoft incorporated the concept of compatibilitylevels into SQL Server 7.0. SQL Server 7.0 has three compatibility levels: 60 for SQL Server 6.0 databases,65 for SQL Server 6.5 databases, and 70 for SQL Server 7.0 databases. These levels let legacy databases in the7.0 environment operate as if they were running under an earlier release of the product. > > The system stored procedure sp_dbcmptlevel lets developers report on and change the compatibility level of their databases.For example, to set the Northwind database to level 65 compatibility, execute the following command: > > sp_dbcmptlevel [Northwind], 65 > > > > Ian Harding > Programmer/Analyst II > Tacoma-Pierce County Health Department > iharding@tpchd.org > (253) 798-3549 > > >>> "scott.marlowe" <scott.marlowe@ihs.com> 12/19/02 01:41PM >>> > On Thu, 19 Dec 2002, Barry Lind wrote: > > > And given one report of a problem, I think that was the correct > > response. I don't think it is wise to add a GUC parameter for every > > change that impacts one person/one app. However if multiple people had > > reported the same problem and the impact of the change was clearly > > understood to negatively impact a large number of users then I am sure a > > GUC parameter would have been added a while ago. > > > > The point I was trying to make is that there were probably a hundred > > changes between 7.2 and 7.3 that could have impacted apps, some > > intentional changes, others not (and it wouldn't make sense to add > > parameters for all of them). Deciding which of these have a significant > > impact on existing apps is part of what the beta period is for. The > > more people that test their apps during the beta period the better > > change we won't have issues like this in the future. > > So, and this is just theorizing, what about having every change that > affects parsing syntacitcally, especially changes like this, be tracked > and handled with a single compatibility GUC var like revert_prev_syntax > that is only around for one version, defaults to off, and handles all the > new versus old syntax. > > That way, when there's a new release, say 7.4 from 7.3, you can just strip > out all the code marked as being turned on by this one GUC and move on > with a new empty spot for revert_prev_syntax. > > Of course, then you might have a problem where reverting to old syntax > takes away a feature someone wants in one area while removing a problem in > another, but, if you need to revert to the previous versions syntax, then > you probably aren't too worried about whether or not you have every single > shiny new feature... > > Just a bit of a ramble. > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I have another interesting idea. What if we create a postgresql.conf
> param called prev_compatible that exists in every release. We default
> it to false/0. If it always exists, we can add features under its
> control even in minor releases. Most interesting would be to have it be
> an int and make a bitmask for up to 32 features that could be made
> backward compatible to the previous release.
Including the definition of the individual bits' behavior?
That strikes me as a mess. No one could ever be very sure what behavior
they were getting or not getting by setting such a thing. But they
could be quite sure that their code would break in interesting ways in
the next release.
If we're going to have compatibility flags, they should be clearly
defined, clearly named, and control just one feature apiece (cf.
transform_null_equals).
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I have another interesting idea. What if we create a postgresql.conf > > param called prev_compatible that exists in every release. We default > > it to false/0. If it always exists, we can add features under its > > control even in minor releases. Most interesting would be to have it be > > an int and make a bitmask for up to 32 features that could be made > > backward compatible to the previous release. > > Including the definition of the individual bits' behavior? > > That strikes me as a mess. No one could ever be very sure what behavior > they were getting or not getting by setting such a thing. But they > could be quite sure that their code would break in interesting ways in > the next release. > > If we're going to have compatibility flags, they should be clearly > defined, clearly named, and control just one feature apiece (cf. > transform_null_equals). You would define the bits in the release notes. postgresql.conf only gets created as part of initdb, and because minor releases don't initdb, it would be easier to have a single variable that always exists. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073