begriffs open source - ai-pg/blob - full-docs/src/sgml/html/parser-stage.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>51.3. The Parser Stage</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="connect-estab.html" title="51.2. How Connections Are Established" /><link rel="next" href="rule-system.html" title="51.4. The PostgreSQL Rule System" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">51.3. The Parser Stage</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="connect-estab.html" title="51.2. How Connections Are Established">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="overview.html" title="Chapter 51. Overview of PostgreSQL Internals">Up</a></td><th width="60%" align="center">Chapter 51. Overview of PostgreSQL Internals</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="rule-system.html" title="51.4. The PostgreSQL Rule System">Next</a></td></tr></table><hr /></div><div class="sect1" id="PARSER-STAGE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">51.3. The Parser Stage <a href="#PARSER-STAGE" class="id_link">#</a></h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="parser-stage.html#PARSER-STAGE-PARSER">51.3.1. Parser</a></span></dt><dt><span class="sect2"><a href="parser-stage.html#PARSER-STAGE-TRANSFORMATION-PROCESS">51.3.2. Transformation Process</a></span></dt></dl></div><p>
   3     The <em class="firstterm">parser stage</em> consists of two parts:
   4
   5     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
   6        The <em class="firstterm">parser</em> defined in
   7        <code class="filename">gram.y</code> and <code class="filename">scan.l</code> is
   8        built using the Unix tools <span class="application">bison</span>
   9        and <span class="application">flex</span>.
  10       </p></li><li class="listitem"><p>
  11        The <em class="firstterm">transformation process</em> does
  12        modifications and augmentations to the data structures returned by the parser.
  13       </p></li></ul></div><p>
  14    </p><div class="sect2" id="PARSER-STAGE-PARSER"><div class="titlepage"><div><div><h3 class="title">51.3.1. Parser <a href="#PARSER-STAGE-PARSER" class="id_link">#</a></h3></div></div></div><p>
  15      The parser has to check the query string (which arrives as plain
  16      text) for valid syntax. If the syntax is correct a
  17      <em class="firstterm">parse tree</em> is built up and handed back;
  18      otherwise an error is returned. The parser and lexer are
  19      implemented using the well-known Unix tools <span class="application">bison</span>
  20      and <span class="application">flex</span>.
  21     </p><p>
  22      The <em class="firstterm">lexer</em> is defined in the file
  23      <code class="filename">scan.l</code> and is responsible
  24      for recognizing <em class="firstterm">identifiers</em>,
  25      the <em class="firstterm">SQL key words</em> etc. For
  26      every key word or identifier that is found, a <em class="firstterm">token</em>
  27      is generated and handed to the parser.
  28     </p><p>
  29      The parser is defined in the file <code class="filename">gram.y</code> and
  30      consists of a set of <em class="firstterm">grammar rules</em> and
  31      <em class="firstterm">actions</em> that are executed whenever a rule
  32      is fired. The code of the actions (which is actually C code) is
  33      used to build up the parse tree.
  34     </p><p>
  35      The file <code class="filename">scan.l</code> is transformed to the C
  36      source file <code class="filename">scan.c</code> using the program
  37      <span class="application">flex</span> and <code class="filename">gram.y</code> is
  38      transformed to <code class="filename">gram.c</code> using
  39      <span class="application">bison</span>.  After these transformations
  40      have taken place a normal C compiler can be used to create the
  41      parser. Never make any changes to the generated C files as they
  42      will be overwritten the next time <span class="application">flex</span>
  43      or <span class="application">bison</span> is called.
  44
  45      </p><div class="note"><h3 class="title">Note</h3><p>
  46        The mentioned transformations and compilations are normally done
  47        automatically using the <em class="firstterm">makefiles</em>
  48        shipped with the <span class="productname">PostgreSQL</span>
  49        source distribution.
  50       </p></div><p>
  51     </p><p>
  52      A detailed description of <span class="application">bison</span> or
  53      the grammar rules given in <code class="filename">gram.y</code> would be
  54      beyond the scope of this manual. There are many books and
  55      documents dealing with <span class="application">flex</span> and
  56      <span class="application">bison</span>. You should be familiar with
  57      <span class="application">bison</span> before you start to study the
  58      grammar given in <code class="filename">gram.y</code> otherwise you won't
  59      understand what happens there.
  60     </p></div><div class="sect2" id="PARSER-STAGE-TRANSFORMATION-PROCESS"><div class="titlepage"><div><div><h3 class="title">51.3.2. Transformation Process <a href="#PARSER-STAGE-TRANSFORMATION-PROCESS" class="id_link">#</a></h3></div></div></div><p>
  61      The parser stage creates a parse tree using only fixed rules about
  62      the syntactic structure of SQL.  It does not make any lookups in the
  63      system catalogs, so there is no possibility to understand the detailed
  64      semantics of the requested operations.  After the parser completes,
  65      the <em class="firstterm">transformation process</em> takes the tree handed
  66      back by the parser as input and does the semantic interpretation needed
  67      to understand which tables, functions, and operators are referenced by
  68      the query.  The data structure that is built to represent this
  69      information is called the <em class="firstterm">query tree</em>.
  70     </p><p>
  71      The reason for separating raw parsing from semantic analysis is that
  72      system catalog lookups can only be done within a transaction, and we
  73      do not wish to start a transaction immediately upon receiving a query
  74      string.  The raw parsing stage is sufficient to identify the transaction
  75      control commands (<code class="command">BEGIN</code>, <code class="command">ROLLBACK</code>, etc.), and
  76      these can then be correctly executed without any further analysis.
  77      Once we know that we are dealing with an actual query (such as
  78      <code class="command">SELECT</code> or <code class="command">UPDATE</code>), it is okay to
  79      start a transaction if we're not already in one.  Only then can the
  80      transformation process be invoked.
  81     </p><p>
  82      The query tree created by the transformation process is structurally
  83      similar to the raw parse tree in most places, but it has many differences
  84      in detail.  For example, a <code class="structname">FuncCall</code> node in the
  85      parse tree represents something that looks syntactically like a function
  86      call.  This might be transformed to either a <code class="structname">FuncExpr</code>
  87      or <code class="structname">Aggref</code> node depending on whether the referenced
  88      name turns out to be an ordinary function or an aggregate function.
  89      Also, information about the actual data types of columns and expression
  90      results is added to the query tree.
  91     </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="connect-estab.html" title="51.2. How Connections Are Established">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="overview.html" title="Chapter 51. Overview of PostgreSQL Internals">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="rule-system.html" title="51.4. The PostgreSQL Rule System">Next</a></td></tr><tr><td width="40%" align="left" valign="top">51.2. How Connections Are Established </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 51.4. The <span class="productname">PostgreSQL</span> Rule System</td></tr></table></div></body></html>