[coverage] Conformance findings: METADATA-038

[peco-engineer-bot]

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-jdbc. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-jdbc) is fixed, then flips green as a tripwire.

Findings

• METADATA-038 [thrift, sea]: getProcedureColumns reports a non-NULL RADIX for INT procedure parameters (raw information_schema numeric_precision_radix passthrough) where radix should be absent for integers
  • failing test: testGetProcedureColumnsProcedureParametersOnlyWithParameterModeMapping (see the coverage PR diff under tests/)

Reproduce & Expected

METADATA-038 — Validates the driver's procedure-PARAMETER metadata call: it reports one row per parameter (and per return value) of a stored PROCEDURE, ordered by parameter position, with each row carrying a parame…

Reproduce:

• Request procedure columns scoped to the temp schema with no column filter
  (catalog = exact temp catalog, schema_pattern = exact temp schema,
  procedure_pattern = null, column_pattern = null).

Expected (per the shared spec):

• completes without an exception
• full assertion contract:

result:
- no_exception: true
  description: The procedure-columns call completes successfully
- type: result_does_not_contain
  column: PROCEDURE_NAME
  expected_absent_values:
  - '{fnName}'
  description: 'No row is reported for the SQL FUNCTION''s arguments (a, b), even
    though

    `information_schema.parameters` holds them. This is the procedures-only

    restriction; it is asserted on every warehouse because it needs only the

    function to exist.

    '
- type: result_columns_complete
  description: "The result carries the driver's full canonical procedure-columns layout\n\
    (JDBC: the 20-column getProcedureColumns set; ODBC: the SQLProcedureColumns\n\
    set) \u2014 not the raw information_schema.parameters columns.\n"
- type: rows_per_parameter_ordered_by_position
  condition: the warehouse supports CREATE PROCEDURE
  description: 'One row per declared parameter of {procName} (plus a return-value
    row if

    the routine has a result), ordered by parameter position.

    '
- type: parameter_direction_mapped
  condition: the warehouse supports CREATE PROCEDURE
  description: 'The direction indicator distinguishes the declared modes: the IN parameter

    (p_in) is reported as input, the OUT parameter (p_out) as output; an

    INOUT parameter is reported as input-output and a return-value row as a

    return, never all collapsed to one value or to "unknown".

    '
- type: type_metadata_resolved
  columns:
  - DATA_TYPE
  - TYPE_NAME
  condition: the warehouse supports CREATE PROCEDURE
  description: "DATA_TYPE is the SQL type code for the declared type (the same mapping\
    \ the\ncolumn-metadata call uses \u2014 e.g. INT and STRING map to their respective\n\
    codes, not to a generic \"other\"), and TYPE_NAME is the declared type name.\n"
- type: radix_reported_only_where_meaningful
  condition: the warehouse supports CREATE PROCEDURE and declares a DECIMAL and a
    DOUBLE parameter
  description: "Radix is 10 for an exact-decimal parameter and 2 for an approximate\n\
    floating-point one, and is absent (NULL) for types where it is not\nmeaningful\
    \ \u2014 including integers, whose source radix is inconsistent.\n"
- type: nullability_reported_unknown
  condition: the warehouse supports CREATE PROCEDURE
  description: 'Because the parameter source carries no nullability, the driver reports

    nullability as UNKNOWN rather than fabricating nullable / not-nullable.

    '
- type: pattern_filter_honoured
  condition: the warehouse supports CREATE PROCEDURE
  description: 'Repeating the call with column_pattern matching one parameter name
    returns

    only that parameter''s row; a column_pattern matching nothing returns zero

    rows without error.

    '

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-kernel/pull/237 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-jdbc; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1246