Andrew Dunstan <andrew@dunslane.net> writes:
> On 02/26/2015 10:56 AM, Tom Lane wrote:
>> I find this argument to be unhelpful, because it could be made in exactly
>> the same words against any non-backwards-compatible change whatsoever.
>> Nonetheless, we do make non-backwards-compatible changes all the time.
> That's true, we do. But finding out where apps are going to break is not
> going to be easy. Reviewing a million lines of code to examine where
> changes in operator precendence might affect you could be an enormous
> undertaking for many users. I understand the need, but the whole
> prospect makes me very, very nervous, TBH.
Well, again, it's not apparent to me why such arguments can't be used
to prevent us from ever again making any user-visible semantics change.
In this particular case, given I've gone to the trouble of creating a
warning mode, I think it would be easier to find potential problems than
it is for many of the compatibility changes we've made in the past.
A not-terribly-far-away example is your own recent change in casting
timestamp values to JSON; if someone had demanded a way to audit their
applications to find places where that might break things, could that
patch have been accepted? Indeed, could *any* of the backwards
compatibility breaks called out in the 9.4 notes have passed such a test?
I'm not honestly sure why we're holding this particular change to such
a high standard.
(Also, I think that most cases in practice are going to end up as parse
errors, not silently different query results, though I admit I haven't
got much evidence one way or the other on that. It'd be useful perhaps
if someone tried some large existing application against the patch to
see what happens. How many parse failures come up, and how many
warnings?)
regards, tom lane
