diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-04 12:17:33 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-04 12:17:33 +0000 |
commit | 5e45211a64149b3c659b90ff2de6fa982a5a93ed (patch) | |
tree | 739caf8c461053357daa9f162bef34516c7bf452 /doc/src/sgml/html/parser-stage.html | |
parent | Initial commit. (diff) | |
download | postgresql-15-5e45211a64149b3c659b90ff2de6fa982a5a93ed.tar.xz postgresql-15-5e45211a64149b3c659b90ff2de6fa982a5a93ed.zip |
Adding upstream version 15.5.upstream/15.5
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/src/sgml/html/parser-stage.html')
-rw-r--r-- | doc/src/sgml/html/parser-stage.html | 91 |
1 files changed, 91 insertions, 0 deletions
diff --git a/doc/src/sgml/html/parser-stage.html b/doc/src/sgml/html/parser-stage.html new file mode 100644 index 0000000..2e41c9a --- /dev/null +++ b/doc/src/sgml/html/parser-stage.html @@ -0,0 +1,91 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!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>52.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="52.2. How Connections Are Established" /><link rel="next" href="rule-system.html" title="52.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">52.3. The Parser Stage</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="connect-estab.html" title="52.2. How Connections Are Established">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Up</a></td><th width="60%" align="center">Chapter 52. Overview of PostgreSQL Internals</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 15.5 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="rule-system.html" title="52.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">52.3. The Parser Stage</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="parser-stage.html#id-1.10.3.6.3">52.3.1. Parser</a></span></dt><dt><span class="sect2"><a href="parser-stage.html#id-1.10.3.6.4">52.3.2. Transformation Process</a></span></dt></dl></div><p> + The <em class="firstterm">parser stage</em> consists of two parts: + + </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> + The <em class="firstterm">parser</em> defined in + <code class="filename">gram.y</code> and <code class="filename">scan.l</code> is + built using the Unix tools <span class="application">bison</span> + and <span class="application">flex</span>. + </p></li><li class="listitem"><p> + The <em class="firstterm">transformation process</em> does + modifications and augmentations to the data structures returned by the parser. + </p></li></ul></div><p> + </p><div class="sect2" id="id-1.10.3.6.3"><div class="titlepage"><div><div><h3 class="title">52.3.1. Parser</h3></div></div></div><p> + The parser has to check the query string (which arrives as plain + text) for valid syntax. If the syntax is correct a + <em class="firstterm">parse tree</em> is built up and handed back; + otherwise an error is returned. The parser and lexer are + implemented using the well-known Unix tools <span class="application">bison</span> + and <span class="application">flex</span>. + </p><p> + The <em class="firstterm">lexer</em> is defined in the file + <code class="filename">scan.l</code> and is responsible + for recognizing <em class="firstterm">identifiers</em>, + the <em class="firstterm">SQL key words</em> etc. For + every key word or identifier that is found, a <em class="firstterm">token</em> + is generated and handed to the parser. + </p><p> + The parser is defined in the file <code class="filename">gram.y</code> and + consists of a set of <em class="firstterm">grammar rules</em> and + <em class="firstterm">actions</em> that are executed whenever a rule + is fired. The code of the actions (which is actually C code) is + used to build up the parse tree. + </p><p> + The file <code class="filename">scan.l</code> is transformed to the C + source file <code class="filename">scan.c</code> using the program + <span class="application">flex</span> and <code class="filename">gram.y</code> is + transformed to <code class="filename">gram.c</code> using + <span class="application">bison</span>. After these transformations + have taken place a normal C compiler can be used to create the + parser. Never make any changes to the generated C files as they + will be overwritten the next time <span class="application">flex</span> + or <span class="application">bison</span> is called. + + </p><div class="note"><h3 class="title">Note</h3><p> + The mentioned transformations and compilations are normally done + automatically using the <em class="firstterm">makefiles</em> + shipped with the <span class="productname">PostgreSQL</span> + source distribution. + </p></div><p> + </p><p> + A detailed description of <span class="application">bison</span> or + the grammar rules given in <code class="filename">gram.y</code> would be + beyond the scope of this manual. There are many books and + documents dealing with <span class="application">flex</span> and + <span class="application">bison</span>. You should be familiar with + <span class="application">bison</span> before you start to study the + grammar given in <code class="filename">gram.y</code> otherwise you won't + understand what happens there. + </p></div><div class="sect2" id="id-1.10.3.6.4"><div class="titlepage"><div><div><h3 class="title">52.3.2. Transformation Process</h3></div></div></div><p> + The parser stage creates a parse tree using only fixed rules about + the syntactic structure of SQL. It does not make any lookups in the + system catalogs, so there is no possibility to understand the detailed + semantics of the requested operations. After the parser completes, + the <em class="firstterm">transformation process</em> takes the tree handed + back by the parser as input and does the semantic interpretation needed + to understand which tables, functions, and operators are referenced by + the query. The data structure that is built to represent this + information is called the <em class="firstterm">query tree</em>. + </p><p> + The reason for separating raw parsing from semantic analysis is that + system catalog lookups can only be done within a transaction, and we + do not wish to start a transaction immediately upon receiving a query + string. The raw parsing stage is sufficient to identify the transaction + control commands (<code class="command">BEGIN</code>, <code class="command">ROLLBACK</code>, etc.), and + these can then be correctly executed without any further analysis. + Once we know that we are dealing with an actual query (such as + <code class="command">SELECT</code> or <code class="command">UPDATE</code>), it is okay to + start a transaction if we're not already in one. Only then can the + transformation process be invoked. + </p><p> + The query tree created by the transformation process is structurally + similar to the raw parse tree in most places, but it has many differences + in detail. For example, a <code class="structname">FuncCall</code> node in the + parse tree represents something that looks syntactically like a function + call. This might be transformed to either a <code class="structname">FuncExpr</code> + or <code class="structname">Aggref</code> node depending on whether the referenced + name turns out to be an ordinary function or an aggregate function. + Also, information about the actual data types of columns and expression + results is added to the query tree. + </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="52.2. How Connections Are Established">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="rule-system.html" title="52.4. The PostgreSQL Rule System">Next</a></td></tr><tr><td width="40%" align="left" valign="top">52.2. How Connections Are Established </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 15.5 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 52.4. The <span class="productname">PostgreSQL</span> Rule System</td></tr></table></div></body></html>
\ No newline at end of file |