this.<name>` resolves to the source relation instead of a same-named colum

[lukapeschke]

What happened?

Related to #6020 . When a column has the same name as a relation, referencing it resolves to the source table instead of the columns.

In a sort, this causes the compilation to fail. In a select, it results in a wildcard select

PRQL input

# Sort case
from status | sort {this.status}

# Select case
from status | select {this.status}

SQL output

# Sort case
from `status` | sort {this.`status`}
                      ──────┬──────
                            ╰──────── table instance cannot be referenced directly

# Select case
SELECT
  *
FROM
  status

Expected SQL output

# Sort case
SELECT * FROM status ORDER BY status.status

# Select case
SELECT status FROM status

MVCE confirmation

• Minimal example
• New issue

Anything else?

No response

[prql-bot]

Thanks for the clear MVCE. I reproduced both cases on main, and also confirmed they still fail on the #6020 branch — so #6020 (which handles a derived column shadowing the relation name) doesn't cover this one; it's a related-but-distinct root cause.

Root cause. A leaf reference like this.status is resolved by Module::lookup, whose lookup_in helper short-circuits to the relation's table instance (NS_SELF) as soon as the leaf name matches an input relation — module.rs#L164-L171. Because that lookup returns a single match (the table instance), resolve_ident_core returns it directly and never reaches the NS_INFER fallback that would infer a same-named column — names.rs#L107-L151. A table instance in select lowers to a wildcard (SELECT *); in sort it hits the table instance cannot be referenced directly error in lowering.rs#L962.

Why it's not a one-line fix. That same short-circuit is what makes referencing a bare relation name expand to all its columns, which is a deliberate feature:

from a | join b (==id) | select {a}   # → SELECT a.* FROM a INNER JOIN b ...
from status | select {status}         # → SELECT * FROM status

Note also that bare status and this.status resolve identically — resolve_ident_core prepends the default this namespace to the bare form, so both take the same lookup path and can't be told apart there.

I tried the naive fix (suppress the NS_SELF short-circuit when the relation is still inferable). It does produce the expected SELECT status FROM status / ORDER BY status here, but it regresses the wildcard behavior above — from a | join b (==id) | select {a} then errors with Ambiguous name (a.a / b.a), and select {status} becomes SELECT status instead of SELECT *. So resolving this comes down to a design decision about how a name that's both a relation and a (possibly inferred) column should disambiguate, and whether leaf this.<relname> should diverge from bare <relname>.

Given that tradeoff and the overlap with the shadowing work in #6020, I'll leave it for a maintainer to decide the intended semantics rather than ship a fix that changes the wildcard behavior.