JDBC driver impl of DatabaseMetadata#getTypeInfo() is rather incomplete

[rsmckinney]

The result returned from DatabaseMetadata#getTypeInfo() is a very small (useless) subset of the SQL types sqlite provides.

1. Run the following on any database:

ResultSet rs = dbMetaData.getTypeInfo();
while (rs.next())
  out.println(rs.getString("TYPE_NAME") + "\t" + JDBCType.valueOf(rs.getInt("DATA_TYPE")).getName());

2. Result:

BLOB	BLOB
INTEGER	INTEGER
NULL	NULL
REAL	REAL
TEXT	VARCHAR

3. As you can see, these mappings only cover a small fraction of the available sqlite SQL types. I was hoping to use this to overcome DatabaseMetaData#getColumns() returns conflicting results for ResultSet#getInt("DATA_TYPE") and ResultSet#getString("TYPE_NAME") #935.
4. Given all the shortcuts taken in this driver wrt type-safety, one has to conclude the implementers don't consider type-safety a worthwhile aspect. If that is the case, please let me know so I can account for that in my project (and stop filing issues here). Thanks.

[gotson]

Sqlite only supports 5 types of data. That function is supposed to return what types are supported, not all jdbc types.

It seems you don't have much understanding on the sqlite type and affinity system, I suggest you read their documentation first.

[rsmckinney]

This issue is a JDBC issue, where types are meaningful. I fully understand SQLite’s loose type system. This issue is about complying with JDBC where table column metadata must agree with query column metadata. Otherwise, your current driver implementation is useless to code generators.

[rsmckinney]

Let me give you an example.

A Java class generated from a table based on metadata obtained from your driver would result in accessors returning strings and integers for columns typed as DATE, TIMESTAMP, TIME, etc. does that sound right to you?