The one thing to understand first
A query string is just text. Between the moment PostgreSQL receives it and the moment a row comes back, that text passes through four distinct machines, each producing a different tree: the <a class="sev1-termlink" href="https://thesev1database.com/glossary/raw-parse-tree/" title="Raw parse tree">raw parse tree (syntax), the query tree (meaning), the plan tree (strategy), and finally the executor that walks the plan to produce rows. Knowing which stage owns which problem is what lets you debug the right thing — a syntax error, a missing table, a bad plan, or a slow execution are four different failures in four different machines.
Where the journey begins: postgres.c
Every backend runs a loop in src/backend/tcop/postgres.c. A simple query (the protocol most tools use) lands in exec_simple_query(), which drives the whole pipeline end to end. The extended protocol splits the same work across exec_parse_message(), exec_bind_message(), and exec_execute_message() — that split is what makes prepared statements and bind parameters possible, but the underlying stages are identical.
Stage 1 — Raw parsing (syntax only)
pg_parse_query() calls raw_parser(), the flex/bison front end (scan.l is the lexer, gram.y the grammar). Its output is a raw parse tree — a list of RawStmt nodes that mirror the SQL’s structure. Crucially, this stage does no catalog lookups: it does not know whether your table exists, only whether the sentence is grammatically valid. A syntax error is the only thing that can fail here.