Skip to content

KL-7: a physical table is dropped entirely when its base name collides with a same-named CTE #16

Description

@devops-den

What it does wrong — the most severe limitation currently tracked

A physical table is dropped from the report entirely when its base name collides with a same-named CTE.

;WITH Country AS (SELECT c.Id FROM dbo.Country c)
SELECT * FROM Country

dbo.Country vanishes from the output completely. The exclusion check that keeps CTE names out of the physical-table list (needed so a CTE never gets reported as if it were a real table) compares by bare base name only, across all schemas — so a CTE named Country makes base in cte_names true for every table literally named Country, anywhere, not just the CTE itself.

Why it matters

This is a table a migration plan needs to know about, silently missing from the report — with no flag, no warning, nothing to distinguish it from "this procedure never touches Country." KL-1/KL-5/KL-6 are wrong-or-missing columns, which is bad but recoverable by re-reading the procedure by hand. This is a whole table gone.

Workaround today: avoid naming CTEs after real tables until this is fixed.

Test

Pinned as a strict-xfail: tests/test_known_limitations.py::test_KL7_physical_table_dropped_when_name_collides_with_cte.

Related: confirmed to generalize further — see the companion issue for KL-7b, which shows this drops any table sharing the name anywhere in the procedure, not just ones reachable through the colliding CTE. Both likely get fixed by the same change (schema-qualified/full-name matching instead of bare-base-name matching in the CTE-exclusion check).

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is neededknown-limitationA documented, pinned parser limitation (see tests/test_known_limitations.py)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions