When generating SQL with use_materialized=True, there's no validation that the requested SQL dialect is compatible with the catalog where the materialized data lives. This can lead to generating SQL that won't execute correctly. AvailabilityState already tracks which catalog the materialized table is in, but this information isn't used to validate dialect compatibility.
We can leverage the existing Catalog -> Engines -> Dialect relationship chain to validate and inform dialect selection.
Implementation:
- Add helper function for dialect compatibility:
async def get_compatible_dialects(session: AsyncSession, catalog_name: str)
- When building SQL with materialized tables, look up the catalog from the availability state and check if requested dialect is in the catalog's compatible dialects.
- Include compatible dialects in relevant API responses so the UI can make informed choices
- Update Query Planner UI to remove hardcoded dialect selection and fetch compatible dialects from API response. Then allow user to select from compatible dialects or auto-select.
When generating SQL with use_materialized=True, there's no validation that the requested SQL dialect is compatible with the catalog where the materialized data lives. This can lead to generating SQL that won't execute correctly.
AvailabilityStatealready tracks which catalog the materialized table is in, but this information isn't used to validate dialect compatibility.We can leverage the existing Catalog -> Engines -> Dialect relationship chain to validate and inform dialect selection.
Implementation: