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