You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We actually also have some code that captures the current database/schema in the model reconciler and other places. I wonder if that can lead to some inconsistencies if the external table storage version gets captured there.
I'm wondering if we should just always return "main" or "" in the information schema listings to give the appearance of it being one schema, and then audit the code to avoid ever making fully qualified table names (i.e. database.schema.table) in our code. If a user has a fully qualified table name in their model code, it's acceptable to error.
The text was updated successfully, but these errors were encountered:
begelundmuller
changed the title
Expose consistent DuckDB schema in the information schema
Handle the DuckDB schema consistently in the information schema
Jan 21, 2025
begelundmuller
changed the title
Handle the DuckDB schema consistently in the information schema
Investigate handling DuckDB schemas safely
Jan 21, 2025
Following up on this thread: https://rilldata.slack.com/archives/CTCJ58H3M/p1736339712522279?thread_ts=1736192001.051219&cid=CTCJ58H3M.
We actually also have some code that captures the current database/schema in the model reconciler and other places. I wonder if that can lead to some inconsistencies if the external table storage version gets captured there.
I'm wondering if we should just always return
"main"
or""
in the information schema listings to give the appearance of it being one schema, and then audit the code to avoid ever making fully qualified table names (i.e.database.schema.table
) in our code. If a user has a fully qualified table name in their model code, it's acceptable to error.The text was updated successfully, but these errors were encountered: