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