Throw if truncation happens but no indicators was provided

[vadz]

Currently if a select statement results in a null value and no indicator is defined for the corresponding output parameter, a "Null value fetched and no indicator defined." exception is thrown. However when the same happens with truncation, it is silently ignored if there is no indicator (if there is one, the truncation is reported via it). This is inconsistent and actually dangerous as the data can be silently corrupted, so we should throw an exception when this happens instead of just ignoring it.

As this would be a backwards incompatible change, it should only be done in 4.0 and not in any of 3.x releases.

[vadz]

So I've finally started working on this. The bad news is that actually no backend even sets the indicator correctly currently, here is the result of the tests:

1. Firebird: indicator is i_ok (the value is, of course, still truncated).
2. MySQL: indicator is i_ok.
3. ODBC using PostgreSQL backend: exception thrown.
4. PostgreSQL: exception thrown.
5. SQLite: indicator is i_ok.

I can't test Oracle which is a pity because, looking at the code, this is the only backend which has some code for returning i_truncated (ODBC backend also has it but clearly this doesn't work there).

Anyhow, I still think that the current situation is wrong, but it's even wronger than I thought and my changes will break the code for all backends (possibly excluding Oracle) as not only will the indicator be set now if available, but also the exception currently thrown by PostgreSQL backend will not be thrown any more. If anybody objects against changing this and sees some other way of fixing this in a more backward compatible manner, please comment.

[vadz]

Update: I have now tested with Oracle too and it behaves as PostgreSQL, i.e. an exception is thrown.

So I actually have a new plan: just make all backends throw an exception on truncation except, perhaps, SQLite, which doesn't lose data (even though it doesn't truncate neither).

The main problem I have with this is that I don't know how to make MySQL generate an exception in non-strict mode, would anybody know how to do it? If not, I'll probably just leave MySQL alone.

[mloskot]

The new plan sounds good 👍

I don't know. @pfedor is our MySQL guru.