[mayuriphad]

Fixes #1638

Heading.set_primary_key built the new heading without table_info, so it lost the connection. When a projection then renamed an attribute of that heading, Heading.select had no adapter and fell back to backtick quoting. That is why (dj.U("b") & T).proj(c="b") compiled to SELECT DISTINCT `b` as "c" and failed on PostgreSQL. MySQL accepts backticks, so it hid the problem there.

set_primary_key now passes table_info=self.table_info, the same way select already hands it on to the heading it builds.

The new unit test in tests/unit/test_pk_rules.py gives a heading a PostgreSQL adapter, calls set_primary_key, then renames an attribute. On master the expression comes out as `b`. With the fix it is "b". tests/unit passes locally (458 passed). I did not run the integration suite because there is no Docker on this machine for the testcontainers.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[dimitri-yatsenko]

Thanks, @mayuriphad. This is the fix for #1638, and the root cause matches what I found when filing it: set_primary_key dropped table_info.

Fork PRs don't trigger CI in this repository at the moment, so I ran it locally on current master:

• Unit tests: tests/unit/test_pk_rules.py passes, including your new test.
• The issue's reproduction: (dj.U("b") & T).proj(c="b") now returns [10, 20] on PostgreSQL and on MySQL.
• Restriction and join tests: tests/integration/test_relational_operand.py passes on both backends.

66 passed in all. A maintainer will follow up on the review.

[MilagrosMarin]

Thanks @mayuriphad, clean and well-scoped fix.

✅ Passing table_info matches what Heading.select already does when it builds its heading
✅ Nice test: it reproduces the issue without needing a database

One possible follow-up (not blocking this PR): Heading.join and Heading.make_subquery_heading also build a new Heading without table_info. Reading the code, a rename after a join, e.g. (A * B).proj(c="b") or a projection of an .aggr result, looks like it would fall back to backticks on PostgreSQL in the same way. I haven't run it to confirm. Worth a quick check, and a separate issue if it reproduces?

LGTM otherwise.

[dimitri-yatsenko]

1. This matches Heading.select(), which already carries table_info forward, and the test reproduces #1638 without a database.
2. The follow-up already raised holds: Heading.join() (heading.py:756) and make_subquery_heading() (:776) also build a Heading without table_info. Worth a follow-up issue, with the same rename test after a join or subquery.
3. CI hasn't run on this PR yet (first-time contributor workflow approval). The run should be approved and pass before merging.

[dimitri-yatsenko]

Thanks again, @mayuriphad. GitHub Actions never ran on this PR, because no workflows ran in this repository between Oct 31 and Nov 9. So I merged it onto current master together with the other approved PRs and ran lint and the full suite locally. Everything passed: 1362 tests on MySQL 8.0 and 8.4, including the tests shared with PostgreSQL, and your new test. Merging.

The follow-up both reviews raised is real. Heading.join() also drops table_info, so a rename after a join, an aggr, or a union still produces backticks on PostgreSQL. #1657 fixes the subquery path, and the rest is tracked in #1676.