This one also looks like a bug to me, I.e., please file also a bug report for this one. Stefan On February 24, 2016 5:23:45 PM CET, Arno Mittelbach wrote:

Done.

And here is a second oddity, that I'd say is a bug. For preparation consider the following simple table with one entry.

Create table a (a varchar(5), b varchar(10)); insert into a values ('12345','1234567890');

Now, the following statement outputs, as expected, 1234567890:

SELECT CASE WHEN 1=2 THEN a ELSE b END from a;

Result: 1234567890

However, when putting in a constant value then MonetDb returns an odd result:

SELECT CASE WHEN 1=2 THEN a ELSE 'lala' END from a;

Result: Px?~

The result is even varying if you run the query multiple times.

Does anybody have any ideas on this one?

Regards, Arno

----- Ursprüngliche Mail ----- Von: "Sjoerd Mullender" An: "users-list" Gesendet: Mittwoch, 24. Februar 2016 16:16:09 Betreff: Re: Typecasting in prepared statements

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Either you have a problem with your locale settings, or this is a bug in MonetDB. Since I can reproduce the problem, I fear it's the latter. Can you please submit a bu report at bugs.monetdb.org? Thanks.

On 24/02/16 16:10, Arno Mittelbach wrote:

...

Hi all,

I am having a strange problem regarding prepared queries with Umlaute (e.g., ä). It seems that the rule for type casting strings correspond to the length of the string. The problem is that an Umlaut seems to count for two "normal" characters. Here is an example. Consider the following simple table:

create table A (a varchar(4));

Now if we create a prepared statement (ultimately I want to do this from Java) such as

prepare select * from A where a = ?;

we can execute the statement and supply 4 characters as the argument:

exec 3('1234');

This works fine. However, if I am using an Umlaut within the parameter, then things don't work out. For example

exec 4('ä123');

fails with the following error message

EXEC: wrong type for argument 1 of prepared statement: char, expected varchar

However, if I now shorten the parameter by "1" character, it works again. That is,

exec 5('ä12');

is ok.

Can anybody explain this behavior? Is this a bug? And is there a workaround? The only thing I came up with so far is to double the size of every column.

Best regards,

Arno

_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list

- -- Sjoerd Mullender -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQEcBAEBCAAGBQJWzck1AAoJEISMxT6LrWYgP7UH/1iinmYn7z3msaCY/t+8yjmM L3P3M80qS/UZpO4vELbtECK6YWM+zlyg5ZzwrFaU1vGLRXJ98l3dJcq0TU8OSWWo TarxJIYM0R0Epb3cCKB3yP98F87F5IAuGxpBqNiGylL4dHw9Puca3HkTPxnFyL2H r13IU+fU43HqRO6Bg7M7B2w2dqwyWhnajPiESd6p88+Emh1CSZKxV8U2DlA5jYZn lSzsf81STdDlVfJ0TYf5zlcSijN8Lgh4nbX6h8+GM/sSxA7C9usFBDLu5m605x13 oEs4BuHy/6yGyR+iH1lp4xHPFa3/Xk/EkOtPsl9CvegJI+kRr6mJtuNexBvQuw8= =Psie -----END PGP SIGNATURE----- _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list

-- | Stefan.Manegold@CWI.nl | DB Architectures (DA) | | www.CWI.nl/~manegold/ | Science Park 123 (L321) | | +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |