David W. Van Couvering wrote: > This is an example where we find our code throwing the wrong SQL > State, but are we allowed to fix it? Lance says yes. Others > providing support for customers say (I think) no. > > This ties into the discussion about the stability classification for > SQL States. If we mark it as Stable, then we can't change this. If > we mark it as Unstable, then we can. > > Comments, thoughts?
I think it is ok and good to change an SQLState or any behaviour to fix a bug if our current behaviour is non-standard. The question becomes what level of notification do we need to users and what strategy will we give them to mitigate the impact of the change? In this case, I think this is new functionality, so all very good it is caught now and dealt with. If it were existing functionality, I think that user notification would be very important. I think we need some way of marking changes that might affect existing users. I made this proposal a while back for Jira that I think would help: http://www.nabble.com/New-Jira-Checkbox-proposal-t1200029.html#a3166517 Feedback from Andrew indicated that components are preferred to checkboxes but being able to query Jira for changes that might affect users I think is important. What do people think of adding components for "Release Note Needed", "Existing Application Impact" and "Regression" ? Kathey
