Daniel John Debrunner wrote:
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.
I don't think we can. One suggestion I received offline was to mark the
standard SQL States as Standard and the Derby-specific SQL States as
Unstable. And then I think I can add a note to the SQLState column that
changes may be permitted in some circumstances, and will be decided on a
case-by-case basis by the community.
Another example if JDBC deprecates some method then how is that
represented in the table?
I don't think it is. I'm not sure if this table is intended for that
level of detail. Do you think it's needed?
Dan.
