Doesn't the database error on ambiguous id?

Only if you write WHERE id = 5 with both tables in scope and neither is qualified — Postgres/SQL Server will error. SELECT * often succeeds and returns both columns. The chat UI or the model then keeps one 'id' and drops the other.

Why does a follow-up question go wrong?

You said 'that id' meaning the order. The model still has customers.id in context from SELECT *. The next query filters the wrong table. No syntax error.

Is this JOIN fan-out?

No. Fan-out multiplies row counts. This is a naming bug: the grain looks like one row per order, but the id you read is the customer's. Totals can still be right while 'open this order' is wrong.

What's the habit that fixes it?

Never SELECT * on a join. List columns with table aliases: o.id AS order_id, c.id AS customer_id. Use those names in filters and in the answer text.

MySQL is looser about ambiguous names in some modes. You can get a silent pick of one id instead of an error. That's worse. Qualify anyway.

Ambiguous ID After SQL JOIN | SELECT *

You ask for "recent orders with the customer name." The table looks fine. You say "show me order 1842." The AI filters WHERE id = 1842 and returns a customer, or nothing, or the wrong order. Both tables have a column named id. After SELECT *, the result has two of them. Something in the pipeline kept one.

Two columns, one label

SELECT *
FROM orders o
JOIN customers c ON c.id = o.customer_id

The result set includes o.id and c.id. Many drivers and chat renderers expose a single id — usually the last one wins, or the first. The model then talks about "id 1842" as if there were one.

SELECT
  o.id AS order_id,
  o.created_at,
  o.amount,
  c.id AS customer_id,
  c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id

Now "order 1842" has a name. A follow-up WHERE o.id = 1842 cannot mean the customer.

This is not fan-out (too many rows) and not latest-row (wrong sibling columns). The row count can be perfect. The identifier is just the other table's.

How to catch it

If a follow-up by id looks insane, ask:

List the column names in the last result, including table aliases.
Which id is the order? Which is the customer?
Re-run with o.id AS order_id, c.id AS customer_id. No SELECT *.

describe_table on both tables before the join would have shown two ids — the same habit as don't guess column names.

The prompt that heads this off

After any JOIN, don't SELECT *. Alias every id: table_id.
Never filter on a bare id when two tables are in scope — use
orders.id or the alias. If I say "that id," confirm which table.

The short version

id after a join is not a unique idea. It's two columns wearing the same name. If "open this order" loads a customer, the model kept the wrong id.

Read-only MCP gateway: mcpserver.design.

Related reading: