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

• Metadata retrieval failure in one catalog results in unablity to retrieve any meta data #16361
• 1 catalog that can't be reached affects all other catalogs (system.jdbc.catalogs)  #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:

# JDBC Driver
* Add a new connection property `assumeNullCatalogMeansCurrent`. Enabling this makes a `null` value for
  `catalog` parameter in `DatabaseMetaData` methods to mean the current catalog. If no current catalog is
  set the behaviour is unmodified.

[cla-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]

LGTM % comments

cc: @electrum this implements the idea mentioned at #16361 (comment) so thought you might want to take a look too.

[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]

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]

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

[github-actions]

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

[github-actions]

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]

LGTM. (No code changes from what was reviewed - rebased on master and just a var rename from Piotr's feedback).

[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.

[mosabua]

Dont we need to document this behavior? Also will this affect the CLI and the JDBC driver? How do we organize farming this change out to other drivers/clients?

[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 !