DatabaseMetaData.getTables: empty types[] matches none instead of all (should equal null) #1570

Summary

databricks-jdbc treats an empty types array in DatabaseMetaData.getTables(catalog, schema, tableNamePattern, new String[]{}) as "match no table types" (returns an empty result), instead of the JDBC-spec behavior where an empty/absent type list matches all table types (equivalent to passing null).

Environment

• driver: databricks-jdbc (OSS) 3.4.x
• both backends (Thrift usethriftclient=1 and SEA usethriftclient=0)

Behavior

// A table exists in the connection's catalog/schema.
DatabaseMetaData md = conn.getMetaData();

// null types → matches all → table IS listed (correct)
md.getTables(cat, schema, tbl, null);          // returns the table ✅

// empty types [] → should also match all, but databricks-jdbc returns EMPTY ❌
md.getTables(cat, schema, tbl, new String[]{}); // returns 0 rows

null and new String[]{} produce different results: null lists the table (match-all), new String[]{} returns nothing (match-none).

Expected

Per the JDBC DatabaseMetaData.getTables contract, types — "a list of table types ... null returns all types" — an empty array carries no type constraint and should match all table types, i.e. behave the same as null (list the table). Reference drivers (e.g. C# ADBC) treat empty-types the same as null.

Repro

Reproduced deterministically via the cross-driver proxy test harness (databricks-driver-test), spec case METADATA-035 ("GetTables - Empty Table Types Filter Matches All"), committed as an xfail tripwire (status: jdbc.{thrift,sea}: bug) asserting the current match-none behavior; it flips to the real match-all assertion once fixed.

Impact

Application code (or ORMs/tools) that pass an empty type array expecting "all tables" get an empty catalog listing, which can silently hide tables during schema discovery.