Yeah, we don't support that kind of metadata at all.

What is your broader use-case for this?

Hi all,
I am working on a set of tools and a runtime that rely heavily on metadata using mostly MySQL and DB2 but we also test with H2, MS-SQL Server and Oracle. In fact, initial development and tests is often done using H2 since it is so convenient. We are now implementing some new feature around stored procedures and arrays. I can no longer use H2 for this work. So if H2 has no plans on supporting these JDBC APIs, I'll have to go to one of our main DBMSs.

Current H2 (compiled from the current sources) provides this information in standard INFORMATION_SCHEMA.ROUTINES, INFORMATION_SCHEMA.PARAMETERS,
INFORMATION_SCHEMA.ELEMENT_TYPES (for arrays) and other tables.

Unfortunately, only some DBMS support SQL/Schemata properly.

On the other hand, callable statements have only very basic implementation in H2. They are rarely used, so nobody carried about their metadata.

On the other hand, callable statements have only very basic implementation in H2. They are rarely used, so nobody carried about their metadata.

I think it would be helpful to think about this in the context of JDBC users and not H2 users. In my case, I use H2 as a placeholder for other databases and as a convenience during development. Saying that callable statements are rarely used in H2 might be true (how would you know?), but it is certainly not the case for the JDBC applications I see.

Saying that callable statements are rarely used in H2 might be true (how would you know?), but it is certainly not the case for the JDBC applications I see.

This is entirely a volunteer developed project, with nobody being paid to work on H2. If you don't like it, feel free to use another project or do the necessary work yourself.

Saying that callable statements are rarely used in H2 might be true (how would you know?), but it is certainly not the case for the JDBC applications I see.

This is entirely a volunteer developed project, with nobody being paid to work on H2. If you don't like it, feel free to use another project or do the necessary work yourself.

I am surprised to see such a negative and dismissive attitude here, quite sad in fact. Over at Apache Commons, Apache HttpComponents, and Apache Log4j, where we are in the same FOSS boat, I'd like to think that I and my fellow volunteers do our best to welcome help, usually by asking for a pull request. Instead, what I read above is "go away". Nice touch.