Swap key lookup for name lookup

○ planned

Type the name you know; SQLly can add the join and make sure the comparison still means what you intended.

Looking for a row hidden behind a foreign key? Type the name you know. SQLly adds the relationship it needs and compares against the readable value, saving you a round of manual JOIN gymnastics.

-- you write
SELECT * FROM orders WHERE customer = 'Acme Corp'

-- SQLly offers
SELECT o.* FROM orders o
  JOIN customers c ON c.id = o.customer_id
 WHERE c.name = 'Acme Corp'

Two ways to get there

This is the more ambitious cousin of FK / name interchangeability, and the difference is worth being clear about:

Approach	What it changes
Name → id (ships today)	Completion resolves the name and inserts the id. Your query stays exactly as you wrote it - a single-table filter on a key column.
Name → join (this page)	SQLly rewrites the query to include the relationship, so the filter reads in terms of the name. More convenient, and a bigger change to your SQL.

It will always be a proposal. Silently adding a join to the statement you are about to run is not acceptable - a join changes cardinality, and a careless one can multiply your rows. So the rewrite is offered as a suggested edit you accept, with the added JOIN visible before it runs.

What it needs to be correct

The relationship - a declared foreign key, or a confidently name-inferred one.
The display column on the referenced table (see smart foreign-key display values).
A check that the join does not change the result's cardinality in a way you did not ask for - which is the part that makes this a careful feature rather than a quick one.

Planned. The relationship model, the display-value resolution, and the join-proposal machinery used by auto join suggestion are all in place; this feature is the composition of them.