[magnusp]

Closes #42. Part of #54.

What changed

LibsqlDatabaseMetaData.getColumns now derives its metadata row from the declared SQLite type and PRAGMA table_xinfo instead of hard-coding BIGINT/OTHER, zero sizes, and IS_AUTOINCREMENT = NO.

• JDBC DATA_TYPE follows xerial's declared-type patterns: INT|BOOL -> Types.INTEGER, CHAR|CLOB|TEXT|BLOB -> Types.VARCHAR, REAL|FLOA|DOUB|DEC|NUM -> Types.FLOAT, catch-all -> Types.VARCHAR.
• COLUMN_SIZE and DECIMAL_DIGITS are parsed from a parenthesized type dimension exactly as xerial does. Untyped/typeless columns keep xerial's defaults (2000000000, 10, or 0 for integer/text).
• TYPE_NAME is the uppercased declared type with the dimension removed.
• NULLABLE/IS_NULLABLE come from the pragma notnull flag.
• IS_AUTOINCREMENT uses the isAutoIncrement false-positives on identifiers containing AUTOINCREMENT #38 helper LibsqlResultSetMetaData.isAutoIncrementColumn on the table's CREATE SQL, gated on the pragma primary-key flag, so no parsing is duplicated and identifiers containing AUTOINCREMENT do not false-positive.
• IS_GENERATEDCOLUMN uses the xerial hidden-column rule (hidden 2 or 3).
• Column/table name patterns still use SQL LIKE with the existing literal escaping, now with an explicit ESCAPE '\'.

The result is assembled from the schema/pragma query in Java and returned as an in-memory LibsqlResultSet, so no extra statement is left open by this metadata call.

Contract decision

xerial 3.53.4.0 JDBC3DatabaseMetaData.getColumns is the contract. The type patterns, defaults, dimension parsing, nullable encoding, and generated-column rule are copied from that implementation. Auto-increment detection intentionally reuses the #38 helper as required by Steering; for a genuine AUTOINCREMENT primary key the result is identical to xerial, while the helper additionally ignores the keyword when it appears in comments, string literals, or non-autoincrement identifiers.

Evidence

Acceptance test: LibsqlDatabaseMetaDataTest.getColumnsReportsDeclaredTypesSizesNullabilityAndAutoIncrement.

Failing before the fix (./mvnw -q -pl libsql-jdbc -am -Dtest=LibsqlDatabaseMetaDataTest -Dsurefire.failIfNoSpecifiedTests=false test):

[ERROR] Tests run: 10, Failures: 0, Errors: 1, Skipped: 0
[ERROR] LibsqlDatabaseMetaDataTest.getColumnsReportsDeclaredTypesSizesNullabilityAndAutoIncrement
java.sql.SQLException: no such column: 'DATA_TYPE'
    at com.github.magnusp.libsql.jdbc.LibsqlResultSet.findColumn(LibsqlResultSet.java:716)

Passing after the fix:

./mvnw -pl libsql-jdbc -am test
Tests run: 163, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

Additional verification run in this environment:

DOCKER_CONFIG=<readable empty config> ./mvnw -pl libsql-itests -am -Dtest=LibsqlJdbcIT ... verify
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0   (twice: surefire + failsafe)

./mvnw -pl libsql-conformance -am verify
Tests run: 115, Failures: 0, Errors: 0, Skipped: 1
BUILD SUCCESS

./mvnw spotless:apply then ./mvnw spotless:check pass.

The pinned xerial 3.53.4.0 was also run directly against the same schema; it reports i INTEGER(4) size 2000000000 digits 0, d DECIMAL(6) size 15 digits 5, k INTEGER(4) autoincrement YES, n TEXT(12) nullable 0.

Deviations

None from xerial.

Note on the acceptance criterion "DECIMAL(10,5) reports size 10 and 5 decimal digits": this cannot be met together with xerial parity. xerial computes COLUMN_SIZE for a two-part dimension as precision + scale, so pinned 3.53.4.0 reports COLUMN_SIZE = 15 for DECIMAL(10,5) (verified by running the pinned jar). This PR follows the binding Steering contract ("match xerial … computed COLUMN_SIZE") and reports 15, with DECIMAL_DIGITS = 5. The test asserts the xerial value and documents the conflict.

No Hrana or sqld limitation was encountered; PRAGMA table_xinfo works against live sqld.