Incident brief
Syntax error
PostgreSQL's parser rejected the statement because it didn't match valid SQL grammar, here, an unquoted reserved key word used as a table name.
What lands in your log
ERROR: syntax error at or near "order"
In 10 seconds
- What triggers it
- Try to CREATE TABLE using a reserved SQL key word as the name, without quoting it.
- Fix
- Quote the identifier with double quotes so PostgreSQL treats it as a name, not a key word.
- Proof
- Reproduced on PostgreSQL 16.14 → Creating a table named order, unquoted, was rejected with SQLSTATE 42601. No table was created.
Fix
What to do right now
Application-level steps for this error.
- Quote the identifier with double quotes so PostgreSQL treats it as a name, not a key word.
- Prefer a name that isn't a reserved word at all, so you don't need to quote it everywhere it's used.
- Quoting only fixes reserved-word collisions, it does not fix an unrelated missing-keyword syntax error, see the premium test.
-- Quote reserved identifiers.
DROP TABLE IF EXISTS "order";
CREATE TABLE "order" (id int);
SELECT id FROM "order";For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Syntax error (42601) is statement-local: PostgreSQL does not retain the rejected value after the statement ends. Capture the exact bound value and statement position in application/server logs, then run this targeted validation before retrying.
Capture parser context before rewriting
Validate the specific value/shape that can raise this SQLSTATE.
SELECT current_setting('server_version_num') AS server_version_num,
current_setting('standard_conforming_strings') AS standard_conforming_strings;
-- Then use the POSITION/caret from the original 42601 message against the
-- exact SQL text sent by the driver, not a reconstructed log line.Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 16 Documentation, Appendix C, SQL Key Words
Even reserved key words are not completely reserved in PostgreSQL, but can be used as column labels (for example, SELECT 55 AS CHECK, even though CHECK is a reserved key word).Read the full section on postgresql.org →
The unquoted CREATE TABLE
order is a reserved key word in PostgreSQL's grammar. Used unquoted as a table name, the parser saw it as a key word, not an identifier, and rejected the statement before any table was created.Confirming nothing was created
pg_tables confirms no table named order exists, the rejected statement had no effect at all.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Try to CREATE TABLE using a reserved SQL key word as the name, without quoting it.
- 2PostgreSQL's parser rejects the statement before it reaches table creation.
- 3SQLSTATE 42601 is reported, pointing at the exact token that broke parsing.
One client: CREATE TABLE using a reserved word as the table name, unquoted.
-- No table needed: the failure happens purely at the parser stage.
SELECT 'no schema required' AS setup_note;CREATE TABLE order (id int);SELECT count(*) FROM pg_tables WHERE tablename = 'order';What PostgreSQL actually returned
setup_note
--------------------
no schema required
(1 row)ERROR: syntax error at or near "order"
LINE 1: CREATE TABLE order (id int);
^ count
-------
0
(1 row)The manual states that even reserved key words can still be used as column labels. This was tested directly, using CHECK, the manual's own example.
Without this
Above: order used as a table name, unquoted, is rejected.
With this, tested
Below: a reserved key word used as a column label, not an identifier, works fine.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- Fix that only works for the reserved-word case, not for syntax errors in general: exact SQL, output, and verdict
- A manual-grounded production interpretation of the lab result
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.