What is the current expectation with using various query or BI tools that uses ODBC/JDBC to fetches metadata and dynamically constructs queries?

[donothangbagsfromthehandlebar]

I'm using greptimedb 1.0.0-beta.1 (8153068) deployed on Kubernetes using the greptimedb-standalone helm chart, have created a few tables and manually inserted some data and then trying to use different odbc/jdbc drivers from tools that fetches metadata and from there constructs queries depending on the user input but these typically fails in various ways when trying to fetch metadata but for example DBeaver using postgres jdbc seems to work fine in that regard.

This can of course be an artifact of these tools are implemented and which standard metadata functions for each driver/technology that the tool are using but at this point in time I'm mainly curious which expectation I should have and if there are plans to better/fully support these kind of tools in the future in order to evaluate if greptimedb can be (sort-of) a drop-in replacement for the current data stores used without having to re-implement the user facing tools immediately (this can of course be done over time if there are better more performant options but that makes such a migration "front-heavy")

Another aspect of this is for example #7253 and #7254 where an existing application using postgres jdbc fails to insert new rows.

[sunng87]

hello @donothangbagsfromthehandlebar , there are two issues within this topic:

1. BI tools support: this is mostly about supporting various startup queries from those BI tools. In greptime, we use datafusion-postgres for that, which is maintained by our people and a few community users. We will list supported BI tools and GUI clients here. It would be helpful if you can create an issue to include the BI tool name and queries it sends to postgres.
2. JDBC insertion issue is another topic that we will resolve in scope of greptimedb or underlying libraries. We will look into those issues soon. And thank you for detailed information about that.