fix: validate catalog parameter of metadata queries (pgjdbc#2947)
Report an error if the catalog parameter is not null or empty, but does not equal the catalog the current connection applies to. This is a breaking change.
NOTE: Even with this change, we are not 100% compatible with the JDBC API, since it would dictate treating an empty String catalog parameter differently from a null one. (The former should query entities that are not associated with any catalog.) Since such entities do not exist in PostgreSQL, returning an empty result would be ideal. However, since the current metadata implementation treats empty schema/table/column/etc. filters no differently from null ones, returning empty results for queries with an empty catalog value would make the driver's behavior inconsistent. (Adjusting how the other filters work, on the other hand, would be a much larger breaking change.)
closes pgjdbc#2947
All Submissions:
- [x] Have you followed the guidelines in our Contributing document?
- [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
New Feature Submissions:
- [x] Does your submission pass tests?
- [x] Does
./gradlew autostyleCheckpass ?
Changes to Existing Features:
- [x] Does this break existing behaviour? If so please explain.
The relevant API calls in PgDatabaseMetaData will no longer accept any kind of string as an input for the catalog filter, as they did previously. (Since previously the value was simply ignored.)
- [x] Have you added an explanation of what your changes do and why you'd like us to include them?
- [x] Have you written new tests for your core changes, as applicable?
- [x] Have you successfully run tests with your changes locally?
This is a breaking change, we would have to mark it as such.
Good point, I was so preoccupied with not wanting to make even bigger breaking changes that I forgot that this already is one. XD Edited the PR and the commit message.
Good point, I was so preoccupied with not wanting to make even bigger breaking changes that I forgot that this already is one. XD Edited the PR and the commit message.
Can you explain the motivation for this change ?
@davecramer As mentioned in #2947, while the driver can only return data for the catalog the connection refers to, this is not enforced in the metadata API at all. Instead, currently, it doesn't matter what the catalog input is for a metadata query, the driver will return results for the current catalog. This is fine for null catalog inputs or inputs that match the connection's catalog, less fine for empty string inputs (but, as I wrote in the PR comment, it's rather difficult to change that), and absolutely disastrous for any other value, because it gives the caller the impression that
- The catalog name they provided exists in the DB
- The returned data applies to that catalog
Neither is necessarily true.
In other words, if the catalog input for metadata queries does not match the connection's catalog, we've been returning completely invalid data until now. This change will cause the driver to throw an error for such queries instead, notifying the caller that the driver is simply incapable of returning metadata for other catalogs because of how PostgreSQL's connections work.