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. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
