Re: JDBC String to Bool spec

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 Jan 16, 2017, at 1:21 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>
>
> On 16 January 2017 at 15:09, Mark Rotteveel <mark(at)lawinegevaar(dot)nl <mailto:mark(at)lawinegevaar(dot)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"
>
>
>
> Dave Cramer
>
> davec(at)postgresintl(dot)com <mailto:davec(at)postgresintl(dot)com>
> www.postgresintl.com <http://www.postgresintl.com/>