Re: Avoiding Application Re-test
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
Import Notes
Reply to msg id not found: 1218118663.4549.516.camel@ebony.2ndQuadrantReference msg id not found: 1218118663.4549.516.camel@ebony.2ndQuadrant
Magnus Hagander <magnus@hagander.net> writes:
Simon Riggs wrote:
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.
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?
Yeah. It's not always possible, and certainly not always easy, to
provide such a behavior. Moreover, an "all or nothing" switch doesn't
seem like it'd be such a big win: presumably, the reason you are updating
to 8.4 is you would like something you can't get in 8.3. So you're
going to have to turn the switch off sooner rather than later, making
the value questionable.
regards, tom lane
Magnus Hagander wrote:
Simon Riggs wrote:
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?
Slightly OT, but just so it's on the record.
I'm of the opinion that whatever packaging system eventually makes it's
way into PG it needs to apply to stuff that's in core at the moment.
That way I can just unload network_addr_types and I no longer have to
worry whether applications might be affected by an incompatible change.
--
Richard Huxton
Archonet Ltd