Add JDBC connection current catalog fallback parameter

[polomek]

Description

This commit introduces fallback (disabled by default), which will try to use catalog value passed through JDBC connection when fetching Trino metadata like: getTables, getColumns, getSchemas with catalog set to null.

Additional context and related issues

• https://github.com/trinodb/trino/issues/16361
• https://github.com/trinodb/trino/issues/1173

Release notes

( ) This is not user-visible or is docs only, and no release notes are required. ( ) Release notes are required. Please propose a release note for me. (x) Release notes are required, with the following suggested text: "Use connection current catalog fallback (disabled by default)"

[cla-bot[bot]]

Thank you for your pull request and welcome to the Trino community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. Continue to work with us on the review and improvements in this PR, and submit the signed CLA to [email protected]. Photos, scans, or digitally-signed PDF files are all suitable. Processing may take a few days. The CLA needs to be on file before we merge your changes. For more information, see https://github.com/trinodb/cla

[hashhar]

also re: commit message, consider this suggestion (i.e. describe why the change is being made and what the change is).

Add JDBC property to use current catalog in metadata if none provided

Some BI tools don't pass a `catalog` when calling the `DatabaseMetaData`
`getTables`, `getColumns` and `getSchemas` methods. This makes the JDBC
driver search across all catalogs which can be expensive.

This commit introduces a new boolean connection property
`assumeNullCatalogMeansCurrentCatalog` (disabled by default) to be used
with such BI tools. If enabled the driver will try to use current
`catalog` of the JDBC connection when fetching Trino metadata like
`getTables`, `getColumns`, `getSchemas` if the `catalog` argument to
those methods is passed as `null`.

[cla-bot[bot]]

Thank you for your pull request and welcome to the Trino community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. Continue to work with us on the review and improvements in this PR, and submit the signed CLA to [email protected]. Photos, scans, or digitally-signed PDF files are all suitable. Processing may take a few days. The CLA needs to be on file before we merge your changes. For more information, see https://github.com/trinodb/cla

[kokosing]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!

[github-actions[bot]]

This pull request has gone a while without any activity. Tagging the Trino developer relations team: @bitsondatadev @colebow @mosabua

[github-actions[bot]]

Closing this pull request, as it has been stale for six weeks. Feel free to re-open at any time.

[kokosing]

This is something we want to merge, but we struggle to reproduce the problem it is fixing.

[findepi]

struggle to reproduce

should be easy with a mock connector

[hashhar]

rebased on master + cleaned up the test a bit

[hashhar]

~actually maybe instead of assumeNullCatalogMeansCurrent it can just be nullCatalogMeansCurrent (specially because MySQL driver has nullDatabaseMeansCurrent (with nullCatalogMeansCurrent being an alias).~

Ignore this, we already have assumeLiteralUnderscoreInMetadataCallsForNonConformingClients, so this name is for internal consistency.

[hashhar]

We can document but it's something for exceptional cases (e.g. BI tools that misuse the DatabaseMetaData APIs, similar to assumeLiteralUnderscoreInMetadataCallsForNonConformingClients).

Doesn't affect either the CLI/JDBC unless enabled. Other clients don't need this since this is added for BI tools which misuse APIs and they use the JDBC driver only.

[mosabua]

Lets leave it as an internal, experts-only thing for now then, and keep an eye out if this problems comes up again.

[kokosing]

Thank you @polomek and @hashhar !