FIR-32802 use catalog parameter in getTables() & getColumns()

[alexradzin]

No description provided.

[ptiurin]

Not sure If catalogs are officially supported yet. Let's check with the relevant team before making changes. We have the columns, but do they actually represent what we want?

[alexradzin]

Not sure If catalogs are officially supported yet. Let's check with the relevant team before making changes. We have the columns, but do they actually represent what we want?

No, it is just a bug. We took catalog into consideration into getSchemas() but just forgot to use it in getTables() and getColumns(). Catalog == Table in our case and in many other databases. The table infomaion_schema.tables has column table_catalog. Morever this column (and similar column from table columumns is returns as a result of getTables() that actually means that the result of returned by this function may be confusing. For example one can call this function sending value foo as as catalog and get result set that supplies value bar when method resultSet.getString("table_cat") is called.

[ptiurin]

Catalog == Table in our case and in many other databases.

We can't assume this as it's incorrect. We're aiming for Postgres compatibility and in Postgres catalog has a specific meaning. JDBC spec also has these two separate.

The table infomaion_schema.tables has column table_catalog.

Yes, but unless it's meaningful we can't start using it. That's why I'm suggesting checking with a relevant team.

[alexradzin]

Again, the API exists. getCatalogs() returns one line that contain the DB name. This means that for consistency getSchemas(), getTables() and getColumns() should respect this parameter as well. At least their result should depend on the value of catalog. At least if the value is "correct", i.e. equals to one that returned by getCatalogs() the list should not be empty; otherwise should be empty.

[ptiurin]

I believe just because we're doing something already doesn't mean it's correct. What I'm saying is, please verify "catalog" matches across the board in get* calls and will stay that way.

[stepansergeevitch]

It seems like catalogs are already supported and return the same value that postgres does
https://docs.firebolt.io/sql_reference/information-schema/tables.html

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[ptiurin]

LGTM, though heads-up this might be a high risk change - we're starting to filter based on previously unfiltered value. Despite this being the "right" way some users might rely on the previous functionality. Let's make sure we at least bump the minor version and include a note in release notes.