> As for me issue 3 is definitely a bug. But this happens because CALL > statement translates elements of array result to columns. For example: > CALL (1,2,3) will return row with 3 columns. Indeed this behavior was > introduced before me (see rev. 2427 Call.query) and I'm not a fan of > this feature at all too but I've kept backward compatibility at time > of my changes.
Ah, I understand. So with the current versions of H2, it is difficult to retrieve an array from a stored function correctly, if using a CallableStatement... While I register only one OUT parameter for the return value with java.sql.Types.ARRAY as a type, I have to retrieve three (or five or seven) values from the CallableStatement. I understand backwards compatibility thoughts. But this design will cause major trouble, should you ever decide to allow for regular OUT parameters as other databases do. Right now, this is not an issue, but HSQLDB also went from Java-based stored functions to a PL/SQL-like syntax with regular OUT parameters. Besides, the current behaviour is inconsistent with calling the function in a normal PreparedStatement as in "select f_arrays1(?) from dual", where an actual Object[] array is returned. In my case, I can hide these facts from client code and always use the PreparedStatement syntax. But for H2, I suggest you remove that "feature" in the next major release. I doubt that a lot of people will rely on that feature, since it isn't really documented. But that's your decision. Cheers Lukas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
