Our experience is that users don't like SQLWarnings, especially if tools log them or even report those warnings to the end-user, and will complain about it to us, instead of disabling said logging or complaining to the tool author. With #802 implemented, there are less warnings than in the past, but it is probably still a good idea to implement something to entirely disable reporting of SQLWarnings.
We should add a connection property and system property to disable reporting (or more properly, registration) of SQLWarning on Connection, Statement and ResultSet (in practice, we never have warnings on ResultSet in the current implementation). As reporting of SQLWarning is mandated by JDBC in some cases, we should report them by default.
Details to be fleshed out in the JDP.
Our experience is that users don't like
SQLWarnings, especially if tools log them or even report those warnings to the end-user, and will complain about it to us, instead of disabling said logging or complaining to the tool author. With #802 implemented, there are less warnings than in the past, but it is probably still a good idea to implement something to entirely disable reporting ofSQLWarnings.We should add a connection property and system property to disable reporting (or more properly, registration) of
SQLWarningonConnection,StatementandResultSet(in practice, we never have warnings onResultSetin the current implementation). As reporting ofSQLWarningis mandated by JDBC in some cases, we should report them by default.Details to be fleshed out in the JDP.