Simon Riggs wrote: > Tom's recent changes to allow hash distinct (yay!) prompted something > that I'd thought about previously. > > Subtle changes in the output of queries can force an application retest, > which then can slow down or prevent an upgrade to the latest release. We > always assume the upgrade itself is the problem, but the biggest barrier > I see is the cost and delay involved in upgrading the application. > > We could invent a new parameter called enable_sort_distinct, but thats > way too specific and horrible. > > What I would like is a parameter called sql_compatibility which has > settings such as 8.3, 8.4 etc.. By default it would have the value 8.4, > but for people that want to upgrade *without* retesting their > application, they could set it to 8.3. > > Every time we introduce a feature that changes output, we just put an if > test in saying sql_compatibility = X, (the release we added feature). > > Straightforward, futureproof. Cool. > > Not foolproof, but still worth it. This would allow many users to > upgrade to 8.4 for new features, yet without changing apps.
Won't there normally be a number of changes that *cannot* be covered by such a parameter, without a whole lot more work in the patch? If so, people will be led to believe they are safe by setting "sql_compatibility=8.3", but really they're not, and they will be annoyed. FWIW, MSSQL has a similar feature. It covers some things and not all. Personally, I find it annoying because vendors think they don't have to re-test since they set it lower, but in reality things still broke. But there are certainly a number of cases where it's useful. I think it comes down to if there how much more work/code will be needed in relation to how many things it will actually be possible to cover with it... //Magnus -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
