The documentation for transform_sql() appears to be slightly out of date.
In the “Custom transformations with .transform_sql()” section, it currently says:
The .transform() method can handle most cases, but it does not automatically upgrade indexes, views or triggers associated with the table that is being transformed.
That is now misleading for indexes and views:
- Indexes on renamed columns are recreated using the new column name.
- Tables referenced by views can be transformed safely.
- View definitions are kept unchanged and continue to point to the live table.
- Triggers are not automatically updated, so that part of the warning is still useful.
I verified this against the current main branch with a table containing an index and a dependent view. After renaming a column with transform(rename=...), the index was recreated against the new column name and the view remained unchanged and queryable when it only referenced an unaffected column.
Could this paragraph be updated to clarify the current behavior? For example:
The .transform() method preserves and recreates indexes where possible, and tables referenced by views can be transformed without repointing those views. View definitions and triggers are not automatically rewritten when their referenced columns change, so those definitions may need to be updated manually.
The existing “Tables referenced by views” section already documents much of this behavior, so this would mainly remove the contradiction between the two sections.
References:
The documentation for transform_sql() appears to be slightly out of date.
In the “Custom transformations with .transform_sql()” section, it currently says:
That is now misleading for indexes and views:
I verified this against the current main branch with a table containing an index and a dependent view. After renaming a column with transform(rename=...), the index was recreated against the new column name and the view remained unchanged and queryable when it only referenced an unaffected column.
Could this paragraph be updated to clarify the current behavior? For example:
The existing “Tables referenced by views” section already documents much of this behavior, so this would mainly remove the contradiction between the two sections.
References: