Well it really isn’t “just “cuz”. The driver is implementing a specification not making up it’s own on the fly. It supposed to align as closely as possible. The ambiguous items make it hard on others (like myself) who work between drivers.
If it was ambiguous from the spec or it was something Postgres supported as an extension I’d say leave it; it doesn’t appear to be either of those.
On 16 January 2017 at 15:09, Mark Rotteveel <mark@lawinegevaar.nl> wrote:On 2017-01-16 20:16, Jorge Solórzano wrote:
I guess you are right, the driver currently blindly converts incorrect
values to false, IMO it should accept only values allowed in
postgresql server since this is the PgJBDC driver, but is should also
support a cast of float, double and decimal as this is required by the
jdbc spec.
Interestingly, the JDBC 4.2 specification documentation allows more types than the apidoc (see my previous email for a quote of the apidoc). I will see if I can get Lance Andersen to amend the apidoc.
The JDBC specification mentions conversion for: TINYINT, SMALLINT, INTEGER, BIGINT, REAL, FLOAT, DOUBLE, DECIMAL, NUMERIC, BIT, BOOLEAN, CHAR, VARCHAR, LONGVARCHAR (and vice versa), the apidoc doesn't mention the fixed and floating point types. Presumably this was added because you can also call getInt on a double, etc.
@vlsi, @davecramer, what is your opinion about blindly convert
incorrect values to false? Should the driver accept this kind of
behaviour?
For instance something like this is allowed (and there is even a test
for this):
CREATE TABLE testboolstring (a varchar(30));
INSERT INTO testboolstring VALUES('this is not true');
when execute rs.getBoolean(1), it gets false, but it should be an
cannotCastException.
You're right, but the question is: will you break existing code if you apply this change?
what does fixing this give us ?
I'm also not in favour of fixing it just "cuz"