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.

Well in this case the functionality has never been in an official
release so I'm sure it can change.

> 
> 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.

I'm beginning to think that the classifications are too broad. I think
there are some exception SQLStates that should should not change and
some that could. In my mind it depends on if a application could be
using the old state in a reasonable way. Very subjective of course, not
sure if we could re-write into a more formal form.

Another example if JDBC deprecates some method then how is that
represented in the table?

Dan.

Reply via email to