krlmlr commented on PR #18:
URL: https://github.com/apache/arrow-adbc/pull/18#issuecomment-1160714111
Yes, that looks about right -- and is still createable with *one single
query* on DuckDB and perhaps Postgres.
--
This is an automated message from the Apache Git Service.
To respond to
krlmlr commented on PR #18:
URL: https://github.com/apache/arrow-adbc/pull/18#issuecomment-1160597922
This is similar to what MySQL does -- others (like Postgres, SQL Server,
DuckDB (?)) would store the `fk_` columns in a detail table
`constraint_column_usage` (we would use a list of
krlmlr commented on PR #18:
URL: https://github.com/apache/arrow-adbc/pull/18#issuecomment-1159752806
Great! I think I can come up with a SQL query that returns this result for
Postgres right from the database, but this is useful only if we support getting
nested data from the database.
krlmlr commented on PR #18:
URL: https://github.com/apache/arrow-adbc/pull/18#issuecomment-1159732527
I wonder if we also should offer a way to expose primary and foreign key,
and perhaps unique constraints. This allows learning the data model from a
remote database.
I have devised
krlmlr commented on PR #18:
URL: https://github.com/apache/arrow-adbc/pull/18#issuecomment-1158246255
Fair enough, we can go with a static output schema for type stability.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and
krlmlr commented on PR #18:
URL: https://github.com/apache/arrow-adbc/pull/18#issuecomment-1158037665
I'm not sure how difficult unpacking will be, and perhaps if filtering by
catalog name we would only get
```
schema_name: utf8
schema_tables: list<...>
```
because
krlmlr commented on PR #18:
URL: https://github.com/apache/arrow-adbc/pull/18#issuecomment-1158022230
Thanks. I wonder if we need that many entry points.
If we assume a hierarchy like catalog -> schema -> table -> column, could we
have one single entry point that returns a nested
