How do I know if my column name is a reserved word?

If describe_table confirms the column exists, spells exactly what's in your query, and it still throws a syntax error — that's the signature. Common offenders: order, group, name, select, table, key, index, date, user, from, where, desc.

Why doesn't the AI just quote every identifier automatically?

Some setups do, but over-quoting isn't free: it forces exact case-sensitivity in Postgres (unquoted identifiers fold to lowercase, quoted ones don't) and can break existing tooling that expects unquoted names. Selective quoting — only when needed — is the safer default most schemas end up with.

Does this differ between Postgres, MySQL, and SQL Server?

Yes, and that's most of the problem. Postgres uses double quotes ("name"), MySQL uses backticks (`name`), SQL Server uses square brackets ([name]). The same reserved word needs three different fixes depending on which database you're connected to.

Can this be fixed so the AI doesn't need to be told every time?

A well-built MCP gateway attaches a hint to the raw error — 'quote reserved identifiers, here's the syntax for your database' — so the model retries correctly in the same turn instead of you diagnosing it manually. Ask your gateway whether it does this before assuming you'll always have to intervene.

Should I just rename the column to avoid this forever?

If you control the schema and it's cheap to migrate, yes — order_date instead of order removes the whole class of bug. If it's a legacy table you can't touch, quoting is the permanent answer, not a workaround.

AI SQL Fails on Reserved Words | Fix Reserved Word Errors

You ask your AI to look at the order column. It runs describe_table, sees the column is really there, spells it back to you correctly — and then the actual query fails with something like syntax error at or near "order" or Incorrect syntax near the keyword 'ORDER'.

Nothing is wrong with the column name. The column name is the problem — because it's also a SQL keyword.

Reserved words: the trap that looks like a typo

ORDER is reserved because of ORDER BY. GROUP is reserved because of GROUP BY. NAME, KEY, INDEX, TABLE, USER, DATE, DESC, SELECT, FROM, WHERE — all of these are legal column names in most schemas, and all of them collide with something the SQL parser expects to see in that exact spot.

Write SELECT order FROM orders and the parser doesn't see "a column called order" — it sees the start of an ORDER BY clause with nothing after it, and throws a syntax error. The AI got the name exactly right. It just wrote it the way you'd write any other identifier, and this identifier isn't like any other.

This is a different failure than the AI guessing a column that doesn't exist. There, describe_table fixes it by showing the real schema. Here, describe_table already ran, already showed the real column — and the query still breaks, because the fix isn't "know the right name," it's "wrap the right name in the right punctuation."

The fix is quoting — and it's different per database

Every major SQL dialect has an escape hatch for using a reserved word (or any identifier with unusual characters/casing) as-is. They just don't agree on the character:

PostgreSQL / Supabase — double quotes: SELECT "order" FROM orders
MySQL — backticks: SELECT `order` FROM orders
SQL Server — square brackets: SELECT [order] FROM orders

Which one is correct depends entirely on which database the AI is connected to right now — the same reserved word needs three different fixes across Postgres, MySQL, and SQL Server. A model that's mostly seen Postgres examples in training will sometimes reach for double quotes against a SQL Server connection and get a second syntax error on top of the first.

There's a quiet side effect worth knowing about Postgres specifically: quoting an identifier also makes it case-sensitive. SELECT "Order" is not the same column as SELECT "order" once you've quoted it, whereas unquoted Order and order both fold to order. This is why gateways don't quote everything by default — it can introduce a second bug while fixing the first if case doesn't match exactly.

What a good error message should do

The raw database error — syntax error at or near "order" — tells the model that something's wrong but not why, so without help it tends to retry with the same broken syntax, or start guessing unrelated fixes (renaming the column, adding a table alias that doesn't help).

A gateway that's paying attention can pattern-match this class of error and attach a hint before handing it back: "quote reserved words used as identifiers — \"name\" in PostgreSQL, [name] in SQL Server" — pointed at the specific dialect the connection is using. The model gets that hint in the same turn as the error and typically self-corrects on the retry, instead of you having to notice the pattern and explain it manually.

If your gateway doesn't do this, you'll see the model bounce between two or three wrong quoting attempts before landing on the right one — annoying, but at least self-limiting, since describe_table already confirmed the column is real.

What to do right now if this happens to you

Confirm it's this and not a wrong name — describe_table should show the exact column spelled correctly
If the query still fails with a plain syntax error near a short, common word (order, group, name), suspect reserved-word quoting before anything else
Tell the model which database you're on if it's not obvious from context, and ask it to quote the identifier using that dialect's syntax
If it's a column you'll query often, consider whether renaming it is cheap enough to make this permanent

This is a small, mechanical failure mode — but it's exactly the kind of thing that makes people conclude "AI can't write real SQL" after one bad afternoon, when the actual fix is three characters of punctuation.

Read-only MCP gateway that attaches self-correction hints to SQL errors: mcpserver.design.

Related reading: