PG
PRO
42602ERRORTier 2 — Caution✅ HIGH confidence

invalid name

Category: Syntax Error or Access Rule ViolationVersions: All Postgres versions

What this means

SQLSTATE 42602 is raised when an identifier (table name, column name, role name, etc.) is syntactically invalid — for example, it contains illegal characters or starts with a digit.

Why it happens

  1. 1An identifier starts with a digit without being quoted
  2. 2An identifier contains special characters that are not permitted in unquoted identifiers
  3. 3Empty identifier (zero-length name) provided

How to reproduce

Creating a table with an invalid unquoted name.

trigger — this will ERROR
CREATE TABLE 123bad (id INT); -- starts with digit
ERROR: invalid name syntax

Fix 1: Quote the identifier with double quotes

When using unconventional identifier names is required.

fix
CREATE TABLE "123bad" (id INT);

Why this works

Double-quoting allows any characters in an identifier, including leading digits, spaces, and special characters. Note that quoted identifiers are case-sensitive.

Fix 2: Rename to a valid unquoted identifier

When the identifier name can be changed.

fix
CREATE TABLE bad_123 (id INT); -- valid: starts with letter

Why this works

Unquoted identifiers must start with a letter or underscore and contain only letters, digits, underscores, and dollar signs.

What not to do

Use quoted identifiers for all identifiers by default

Why it's wrong: Quoted identifiers are case-sensitive, which can cause surprising behaviour when mixed with case-insensitive unquoted identifiers.

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

🔧 Source ref: Class 42 — Syntax Error or Access Rule Violation

Confidence assessment

✅ HIGH confidence

Standard SQLSTATE for identifier validation. Stable across all versions.

See also

📄 Reference pages

IdentifiersSQL Naming
⚙️ This error reference was generated with AI assistance and reviewed for accuracy. Examples are provided to illustrate common scenarios and may not cover every case. Always test fixes in a development environment before applying to production. Spotted an error? Suggest a correction →