Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

format: granularity for constraints in AdbcConnectionGetObjects #1508

Open
CurtHagenlocher opened this issue Feb 2, 2024 · 3 comments
Open

Comments

@CurtHagenlocher
Copy link
Contributor

Fetching constraints can be quite expensive if they're not going to be needed. AdbcConnectionGetObjects doesn't make it possible to get tables or columns without also fetching constraints. There should be a way to do so.

@lidavidm
Copy link
Member

lidavidm commented Feb 2, 2024

I'm also willing to consider breaking up getObjects to be less monolithic

@CurtHagenlocher
Copy link
Contributor Author

I wonder whether we need an overall tracking item for metadata-related APIs. For now, I'm going to add an unrelated complaint to this one. The spec for GetObjects says

Some functions accept "search pattern" arguments, which are strings that can contain the special character "%" to match zero or more characters, or "_" to match exactly one character. (See the documentation of DatabaseMetaData in JDBC or "Pattern Value Arguments" in the ODBC documentation.) Escaping is not currently supported.

The lack of support for escaping means that fetching metadata for a table in a schema named release_test can be significantly slower than fetching metadata for a table in a schema named releasetest.

@lidavidm
Copy link
Member

lidavidm commented Jun 4, 2024

Ah, I think what we're missing is the equivalent of https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/DatabaseMetaData.html#getSearchStringEscape()

There are other issues asking about having the driver escape things; it might be good to provide those + provide a way to escape the search pattern per-driver (since it appears this is not commonly standardized unlike the pattern characters)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants