Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
Watch 1
Star 0
Wiki 捐赠
gooderp18绿色标准版
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Tree: 0f75e31513
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '0f75e31513'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/sql-syntax-lexical.html

678 lines
47KB
Raw Blame History 

  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>4.1. Lexical Structure</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 V1.79.1" /><link rel="prev" href="sql-syntax.html" title="Chapter 4. SQL Syntax" /><link rel="next" href="sql-expressions.html" title="4.2. Value Expressions" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">4.1. Lexical Structure</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="sql-syntax.html" title="Chapter 4. SQL Syntax">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="sql-syntax.html" title="Chapter 4. SQL Syntax">Up</a></td><th width="60%" align="center">Chapter 4. SQL Syntax</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="sql-expressions.html" title="4.2. Value Expressions">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="SQL-SYNTAX-LEXICAL"><div class="titlepage"><div><div><h2 class="title" style="clear: both">4.1. Lexical Structure</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS">4.1.1. Identifiers and Key Words</a></span></dt><dt><span class="sect2"><a href="sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS">4.1.2. Constants</a></span></dt><dt><span class="sect2"><a href="sql-syntax-lexical.html#SQL-SYNTAX-OPERATORS">4.1.3. Operators</a></span></dt><dt><span class="sect2"><a href="sql-syntax-lexical.html#SQL-SYNTAX-SPECIAL-CHARS">4.1.4. Special Characters</a></span></dt><dt><span class="sect2"><a href="sql-syntax-lexical.html#SQL-SYNTAX-COMMENTS">4.1.5. Comments</a></span></dt><dt><span class="sect2"><a href="sql-syntax-lexical.html#SQL-PRECEDENCE">4.1.6. Operator Precedence</a></span></dt></dl></div><a id="id-1.5.3.5.2" class="indexterm"></a><p>

  3.    SQL input consists of a sequence of

  4.    <em class="firstterm">commands</em>.  A command is composed of a

  5.    sequence of <em class="firstterm">tokens</em>, terminated by a

  6.    semicolon (<span class="quote">“<span class="quote">;</span>”</span>).  The end of the input stream also

  7.    terminates a command.  Which tokens are valid depends on the syntax

  8.    of the particular command.

  9.   </p><p>

  10.    A token can be a <em class="firstterm">key word</em>, an

  11.    <em class="firstterm">identifier</em>, a <em class="firstterm">quoted

  12.    identifier</em>, a <em class="firstterm">literal</em> (or

  13.    constant), or a special character symbol.  Tokens are normally

  14.    separated by whitespace (space, tab, newline), but need not be if

  15.    there is no ambiguity (which is generally only the case if a

  16.    special character is adjacent to some other token type).

  17.   </p><p>

  18.     For example, the following is (syntactically) valid SQL input:

  19. </p><pre class="programlisting">

  20. SELECT * FROM MY_TABLE;

  21. UPDATE MY_TABLE SET A = 5;

  22. INSERT INTO MY_TABLE VALUES (3, 'hi there');

  23. </pre><p>

  24.     This is a sequence of three commands, one per line (although this

  25.     is not required; more than one command can be on a line, and

  26.     commands can usefully be split across lines).

  27.    </p><p>

  28.    Additionally, <em class="firstterm">comments</em> can occur in SQL

  29.    input.  They are not tokens, they are effectively equivalent to

  30.    whitespace.

  31.   </p><p>

  32.    The SQL syntax is not very consistent regarding what tokens

  33.    identify commands and which are operands or parameters.  The first

  34.    few tokens are generally the command name, so in the above example

  35.    we would usually speak of a <span class="quote">“<span class="quote">SELECT</span>”</span>, an

  36.    <span class="quote">“<span class="quote">UPDATE</span>”</span>, and an <span class="quote">“<span class="quote">INSERT</span>”</span> command.  But

  37.    for instance the <code class="command">UPDATE</code> command always requires

  38.    a <code class="token">SET</code> token to appear in a certain position, and

  39.    this particular variation of <code class="command">INSERT</code> also

  40.    requires a <code class="token">VALUES</code> in order to be complete.  The

  41.    precise syntax rules for each command are described in <a class="xref" href="reference.html" title="Part VI. Reference">Part VI</a>.

  42.   </p><div class="sect2" id="SQL-SYNTAX-IDENTIFIERS"><div class="titlepage"><div><div><h3 class="title">4.1.1. Identifiers and Key Words</h3></div></div></div><a id="id-1.5.3.5.8.2" class="indexterm"></a><a id="id-1.5.3.5.8.3" class="indexterm"></a><a id="id-1.5.3.5.8.4" class="indexterm"></a><p>

  43.     Tokens such as <code class="token">SELECT</code>, <code class="token">UPDATE</code>, or

  44.     <code class="token">VALUES</code> in the example above are examples of

  45.     <em class="firstterm">key words</em>, that is, words that have a fixed

  46.     meaning in the SQL language.  The tokens <code class="token">MY_TABLE</code>

  47.     and <code class="token">A</code> are examples of

  48.     <em class="firstterm">identifiers</em>.  They identify names of

  49.     tables, columns, or other database objects, depending on the

  50.     command they are used in.  Therefore they are sometimes simply

  51.     called <span class="quote">“<span class="quote">names</span>”</span>.  Key words and identifiers have the

  52.     same lexical structure, meaning that one cannot know whether a

  53.     token is an identifier or a key word without knowing the language.

  54.     A complete list of key words can be found in <a class="xref" href="sql-keywords-appendix.html" title="Appendix C. SQL Key Words">Appendix C</a>.

  55.    </p><p>

  56.     SQL identifiers and key words must begin with a letter

  57.     (<code class="literal">a</code>-<code class="literal">z</code>, but also letters with

  58.     diacritical marks and non-Latin letters) or an underscore

  59.     (<code class="literal">_</code>).  Subsequent characters in an identifier or

  60.     key word can be letters, underscores, digits

  61.     (<code class="literal">0</code>-<code class="literal">9</code>), or dollar signs

  62.     (<code class="literal">$</code>).  Note that dollar signs are not allowed in identifiers

  63.     according to the letter of the SQL standard, so their use might render

  64.     applications less portable.

  65.     The SQL standard will not define a key word that contains

  66.     digits or starts or ends with an underscore, so identifiers of this

  67.     form are safe against possible conflict with future extensions of the

  68.     standard.

  69.    </p><p>

  70.     <a id="id-1.5.3.5.8.7.1" class="indexterm"></a>

  71.     The system uses no more than <code class="symbol">NAMEDATALEN</code>-1

  72.     bytes of an identifier; longer names can be written in

  73.     commands, but they will be truncated.  By default,

  74.     <code class="symbol">NAMEDATALEN</code> is 64 so the maximum identifier

  75.     length is 63 bytes. If this limit is problematic, it can be raised by

  76.     changing the <code class="symbol">NAMEDATALEN</code> constant in

  77.     <code class="filename">src/include/pg_config_manual.h</code>.

  78.    </p><p>

  79.     <a id="id-1.5.3.5.8.8.1" class="indexterm"></a>

  80.     Key words and unquoted identifiers are case insensitive.  Therefore:

  81. </p><pre class="programlisting">

  82. UPDATE MY_TABLE SET A = 5;

  83. </pre><p>

  84.     can equivalently be written as:

  85. </p><pre class="programlisting">

  86. uPDaTE my_TabLE SeT a = 5;

  87. </pre><p>

  88.     A convention often used is to write key words in upper

  89.     case and names in lower case, e.g.:

  90. </p><pre class="programlisting">

  91. UPDATE my_table SET a = 5;

  92. </pre><p>

  93.    </p><p>

  94.     <a id="id-1.5.3.5.8.9.1" class="indexterm"></a>

  95.     There is a second kind of identifier:  the <em class="firstterm">delimited

  96.     identifier</em> or <em class="firstterm">quoted

  97.     identifier</em>.  It is formed by enclosing an arbitrary

  98.     sequence of characters in double-quotes

  99.     (<code class="literal">"</code>).  A delimited

  100.     identifier is always an identifier, never a key word.  So

  101.     <code class="literal">"select"</code> could be used to refer to a column or

  102.     table named <span class="quote">“<span class="quote">select</span>”</span>, whereas an unquoted

  103.     <code class="literal">select</code> would be taken as a key word and

  104.     would therefore provoke a parse error when used where a table or

  105.     column name is expected.  The example can be written with quoted

  106.     identifiers like this:

  107. </p><pre class="programlisting">

  108. UPDATE "my_table" SET "a" = 5;

  109. </pre><p>

  110.    </p><p>

  111.     Quoted identifiers can contain any character, except the character

  112.     with code zero.  (To include a double quote, write two double quotes.)

  113.     This allows constructing table or column names that would

  114.     otherwise not be possible, such as ones containing spaces or

  115.     ampersands.  The length limitation still applies.

  116.    </p><a id="id-1.5.3.5.8.11" class="indexterm"></a><p>

  117.     A variant of quoted

  118.     identifiers allows including escaped Unicode characters identified

  119.     by their code points.  This variant starts

  120.     with <code class="literal">U&amp;</code> (upper or lower case U followed by

  121.     ampersand) immediately before the opening double quote, without

  122.     any spaces in between, for example <code class="literal">U&amp;"foo"</code>.

  123.     (Note that this creates an ambiguity with the

  124.     operator <code class="literal">&amp;</code>.  Use spaces around the operator to

  125.     avoid this problem.)  Inside the quotes, Unicode characters can be

  126.     specified in escaped form by writing a backslash followed by the

  127.     four-digit hexadecimal code point number or alternatively a

  128.     backslash followed by a plus sign followed by a six-digit

  129.     hexadecimal code point number.  For example, the

  130.     identifier <code class="literal">"data"</code> could be written as

  131. </p><pre class="programlisting">

  132. U&amp;"d\0061t\+000061"

  133. </pre><p>

  134.     The following less trivial example writes the Russian

  135.     word <span class="quote">“<span class="quote">slon</span>”</span> (elephant) in Cyrillic letters:

  136. </p><pre class="programlisting">

  137. U&amp;"\0441\043B\043E\043D"

  138. </pre><p>

  139.    </p><p>

  140.     If a different escape character than backslash is desired, it can

  141.     be specified using

  142.     the <code class="literal">UESCAPE</code><a id="id-1.5.3.5.8.13.2" class="indexterm"></a>

  143.     clause after the string, for example:

  144. </p><pre class="programlisting">

  145. U&amp;"d!0061t!+000061" UESCAPE '!'

  146. </pre><p>

  147.     The escape character can be any single character other than a

  148.     hexadecimal digit, the plus sign, a single quote, a double quote,

  149.     or a whitespace character.  Note that the escape character is

  150.     written in single quotes, not double quotes.

  151.    </p><p>

  152.     To include the escape character in the identifier literally, write

  153.     it twice.

  154.    </p><p>

  155.     The Unicode escape syntax works only when the server encoding is

  156.     <code class="literal">UTF8</code>.  When other server encodings are used, only code

  157.     points in the ASCII range (up to <code class="literal">\007F</code>) can be

  158.     specified.  Both the 4-digit and the 6-digit form can be used to

  159.     specify UTF-16 surrogate pairs to compose characters with code

  160.     points larger than U+FFFF, although the availability of the

  161.     6-digit form technically makes this unnecessary.  (Surrogate

  162.     pairs are not stored directly, but combined into a single

  163.     code point that is then encoded in UTF-8.)

  164.    </p><p>

  165.     Quoting an identifier also makes it case-sensitive, whereas

  166.     unquoted names are always folded to lower case.  For example, the

  167.     identifiers <code class="literal">FOO</code>, <code class="literal">foo</code>, and

  168.     <code class="literal">"foo"</code> are considered the same by

  169.     <span class="productname">PostgreSQL</span>, but

  170.     <code class="literal">"Foo"</code> and <code class="literal">"FOO"</code> are

  171.     different from these three and each other.  (The folding of

  172.     unquoted names to lower case in <span class="productname">PostgreSQL</span> is

  173.     incompatible with the SQL standard, which says that unquoted names

  174.     should be folded to upper case.  Thus, <code class="literal">foo</code>

  175.     should be equivalent to <code class="literal">"FOO"</code> not

  176.     <code class="literal">"foo"</code> according to the standard.  If you want

  177.     to write portable applications you are advised to always quote a

  178.     particular name or never quote it.)

  179.    </p></div><div class="sect2" id="SQL-SYNTAX-CONSTANTS"><div class="titlepage"><div><div><h3 class="title">4.1.2. Constants</h3></div></div></div><a id="id-1.5.3.5.9.2" class="indexterm"></a><p>

  180.     There are three kinds of <em class="firstterm">implicitly-typed

  181.     constants</em> in <span class="productname">PostgreSQL</span>:

  182.     strings, bit strings, and numbers.

  183.     Constants can also be specified with explicit types, which can

  184.     enable more accurate representation and more efficient handling by

  185.     the system. These alternatives are discussed in the following

  186.     subsections.

  187.    </p><div class="sect3" id="SQL-SYNTAX-STRINGS"><div class="titlepage"><div><div><h4 class="title">4.1.2.1. String Constants</h4></div></div></div><a id="id-1.5.3.5.9.4.2" class="indexterm"></a><p>

  188.      <a id="id-1.5.3.5.9.4.3.1" class="indexterm"></a>

  189.      A string constant in SQL is an arbitrary sequence of characters

  190.      bounded by single quotes (<code class="literal">'</code>), for example

  191.      <code class="literal">'This is a string'</code>.  To include

  192.      a single-quote character within a string constant,

  193.      write two adjacent single quotes, e.g.,

  194.      <code class="literal">'Dianne''s horse'</code>.

  195.      Note that this is <span class="emphasis"><em>not</em></span> the same as a double-quote

  196.      character (<code class="literal">"</code>). 

  197.     </p><p>

  198.      Two string constants that are only separated by whitespace

  199.      <span class="emphasis"><em>with at least one newline</em></span> are concatenated

  200.      and effectively treated as if the string had been written as one

  201.      constant.  For example:

  202. </p><pre class="programlisting">

  203. SELECT 'foo'

  204. 'bar';

  205. </pre><p>

  206.      is equivalent to:

  207. </p><pre class="programlisting">

  208. SELECT 'foobar';

  209. </pre><p>

  210.      but:

  211. </p><pre class="programlisting">

  212. SELECT 'foo'      'bar';

  213. </pre><p>

  214.      is not valid syntax.  (This slightly bizarre behavior is specified

  215.      by <acronym class="acronym">SQL</acronym>; <span class="productname">PostgreSQL</span> is

  216.      following the standard.)

  217.     </p></div><div class="sect3" id="SQL-SYNTAX-STRINGS-ESCAPE"><div class="titlepage"><div><div><h4 class="title">4.1.2.2. String Constants with C-Style Escapes</h4></div></div></div><a id="id-1.5.3.5.9.5.2" class="indexterm"></a><a id="id-1.5.3.5.9.5.3" class="indexterm"></a><p>

  218.      <span class="productname">PostgreSQL</span> also accepts <span class="quote">“<span class="quote">escape</span>”</span>

  219.      string constants, which are an extension to the SQL standard.

  220.      An escape string constant is specified by writing the letter

  221.      <code class="literal">E</code> (upper or lower case) just before the opening single

  222.      quote, e.g., <code class="literal">E'foo'</code>.  (When continuing an escape string

  223.      constant across lines, write <code class="literal">E</code> only before the first opening

  224.      quote.)

  225.      Within an escape string, a backslash character (<code class="literal">\</code>) begins a

  226.      C-like <em class="firstterm">backslash escape</em> sequence, in which the combination

  227.      of backslash and following character(s) represent a special byte

  228.      value, as shown in <a class="xref" href="sql-syntax-lexical.html#SQL-BACKSLASH-TABLE" title="Table 4.1. Backslash Escape Sequences">Table 4.1</a>.

  229.     </p><div class="table" id="SQL-BACKSLASH-TABLE"><p class="title"><strong>Table 4.1. Backslash Escape Sequences</strong></p><div class="table-contents"><table class="table" summary="Backslash Escape Sequences" border="1"><colgroup><col /><col /></colgroup><thead><tr><th>Backslash Escape Sequence</th><th>Interpretation</th></tr></thead><tbody><tr><td><code class="literal">\b</code></td><td>backspace</td></tr><tr><td><code class="literal">\f</code></td><td>form feed</td></tr><tr><td><code class="literal">\n</code></td><td>newline</td></tr><tr><td><code class="literal">\r</code></td><td>carriage return</td></tr><tr><td><code class="literal">\t</code></td><td>tab</td></tr><tr><td>

  230.          <code class="literal">\<em class="replaceable"><code>o</code></em></code>,

  231.          <code class="literal">\<em class="replaceable"><code>oo</code></em></code>,

  232.          <code class="literal">\<em class="replaceable"><code>ooo</code></em></code>

  233.          (<em class="replaceable"><code>o</code></em> = 0 - 7)

  234.         </td><td>octal byte value</td></tr><tr><td>

  235.          <code class="literal">\x<em class="replaceable"><code>h</code></em></code>,

  236.          <code class="literal">\x<em class="replaceable"><code>hh</code></em></code>

  237.          (<em class="replaceable"><code>h</code></em> = 0 - 9, A - F)

  238.         </td><td>hexadecimal byte value</td></tr><tr><td>

  239.          <code class="literal">\u<em class="replaceable"><code>xxxx</code></em></code>,

  240.          <code class="literal">\U<em class="replaceable"><code>xxxxxxxx</code></em></code>

  241.          (<em class="replaceable"><code>x</code></em> = 0 - 9, A - F)

  242.         </td><td>16 or 32-bit hexadecimal Unicode character value</td></tr></tbody></table></div></div><br class="table-break" /><p>

  243.      Any other

  244.      character following a backslash is taken literally. Thus, to

  245.      include a backslash character, write two backslashes (<code class="literal">\\</code>).

  246.      Also, a single quote can be included in an escape string by writing

  247.      <code class="literal">\'</code>, in addition to the normal way of <code class="literal">''</code>.

  248.     </p><p>

  249.      It is your responsibility that the byte sequences you create,

  250.      especially when using the octal or hexadecimal escapes, compose

  251.      valid characters in the server character set encoding.  When the

  252.      server encoding is UTF-8, then the Unicode escapes or the

  253.      alternative Unicode escape syntax, explained

  254.      in <a class="xref" href="sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE" title="4.1.2.3. String Constants with Unicode Escapes">Section 4.1.2.3</a>, should be used

  255.      instead.  (The alternative would be doing the UTF-8 encoding by

  256.      hand and writing out the bytes, which would be very cumbersome.)

  257.     </p><p>

  258.      The Unicode escape syntax works fully only when the server

  259.      encoding is <code class="literal">UTF8</code>.  When other server encodings are

  260.      used, only code points in the ASCII range (up

  261.      to <code class="literal">\u007F</code>) can be specified.  Both the 4-digit and

  262.      the 8-digit form can be used to specify UTF-16 surrogate pairs to

  263.      compose characters with code points larger than U+FFFF, although

  264.      the availability of the 8-digit form technically makes this

  265.      unnecessary.  (When surrogate pairs are used when the server

  266.      encoding is <code class="literal">UTF8</code>, they are first combined into a

  267.      single code point that is then encoded in UTF-8.)

  268.     </p><div class="caution"><h3 class="title">Caution</h3><p>

  269.      If the configuration parameter

  270.      <a class="xref" href="runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS">standard_conforming_strings</a> is <code class="literal">off</code>,

  271.      then <span class="productname">PostgreSQL</span> recognizes backslash escapes

  272.      in both regular and escape string constants.  However, as of

  273.      <span class="productname">PostgreSQL</span> 9.1, the default is <code class="literal">on</code>, meaning

  274.      that backslash escapes are recognized only in escape string constants.

  275.      This behavior is more standards-compliant, but might break applications

  276.      which rely on the historical behavior, where backslash escapes

  277.      were always recognized.  As a workaround, you can set this parameter

  278.      to <code class="literal">off</code>, but it is better to migrate away from using backslash

  279.      escapes.  If you need to use a backslash escape to represent a special

  280.      character, write the string constant with an <code class="literal">E</code>.

  281.     </p><p>

  282.      In addition to <code class="varname">standard_conforming_strings</code>, the configuration

  283.      parameters <a class="xref" href="runtime-config-compatible.html#GUC-ESCAPE-STRING-WARNING">escape_string_warning</a> and

  284.      <a class="xref" href="runtime-config-compatible.html#GUC-BACKSLASH-QUOTE">backslash_quote</a> govern treatment of backslashes

  285.      in string constants.

  286.     </p></div><p>

  287.      The character with the code zero cannot be in a string constant.

  288.     </p></div><div class="sect3" id="SQL-SYNTAX-STRINGS-UESCAPE"><div class="titlepage"><div><div><h4 class="title">4.1.2.3. String Constants with Unicode Escapes</h4></div></div></div><a id="id-1.5.3.5.9.6.2" class="indexterm"></a><p>

  289.      <span class="productname">PostgreSQL</span> also supports another type

  290.      of escape syntax for strings that allows specifying arbitrary

  291.      Unicode characters by code point.  A Unicode escape string

  292.      constant starts with <code class="literal">U&amp;</code> (upper or lower case

  293.      letter U followed by ampersand) immediately before the opening

  294.      quote, without any spaces in between, for

  295.      example <code class="literal">U&amp;'foo'</code>.  (Note that this creates an

  296.      ambiguity with the operator <code class="literal">&amp;</code>.  Use spaces

  297.      around the operator to avoid this problem.)  Inside the quotes,

  298.      Unicode characters can be specified in escaped form by writing a

  299.      backslash followed by the four-digit hexadecimal code point

  300.      number or alternatively a backslash followed by a plus sign

  301.      followed by a six-digit hexadecimal code point number.  For

  302.      example, the string <code class="literal">'data'</code> could be written as

  303. </p><pre class="programlisting">

  304. U&amp;'d\0061t\+000061'

  305. </pre><p>

  306.      The following less trivial example writes the Russian

  307.      word <span class="quote">“<span class="quote">slon</span>”</span> (elephant) in Cyrillic letters:

  308. </p><pre class="programlisting">

  309. U&amp;'\0441\043B\043E\043D'

  310. </pre><p>

  311.     </p><p>

  312.      If a different escape character than backslash is desired, it can

  313.      be specified using

  314.      the <code class="literal">UESCAPE</code><a id="id-1.5.3.5.9.6.4.2" class="indexterm"></a>

  315.      clause after the string, for example:

  316. </p><pre class="programlisting">

  317. U&amp;'d!0061t!+000061' UESCAPE '!'

  318. </pre><p>

  319.      The escape character can be any single character other than a

  320.      hexadecimal digit, the plus sign, a single quote, a double quote,

  321.      or a whitespace character.

  322.     </p><p>

  323.      The Unicode escape syntax works only when the server encoding is

  324.      <code class="literal">UTF8</code>.  When other server encodings are used, only

  325.      code points in the ASCII range (up to <code class="literal">\007F</code>)

  326.      can be specified.  Both the 4-digit and the 6-digit form can be

  327.      used to specify UTF-16 surrogate pairs to compose characters with

  328.      code points larger than U+FFFF, although the availability of the

  329.      6-digit form technically makes this unnecessary.  (When surrogate

  330.      pairs are used when the server encoding is <code class="literal">UTF8</code>, they

  331.      are first combined into a single code point that is then encoded

  332.      in UTF-8.)

  333.     </p><p>

  334.      Also, the Unicode escape syntax for string constants only works

  335.      when the configuration

  336.      parameter <a class="xref" href="runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS">standard_conforming_strings</a> is

  337.      turned on.  This is because otherwise this syntax could confuse

  338.      clients that parse the SQL statements to the point that it could

  339.      lead to SQL injections and similar security issues.  If the

  340.      parameter is set to off, this syntax will be rejected with an

  341.      error message.

  342.     </p><p>

  343.      To include the escape character in the string literally, write it

  344.      twice.

  345.     </p></div><div class="sect3" id="SQL-SYNTAX-DOLLAR-QUOTING"><div class="titlepage"><div><div><h4 class="title">4.1.2.4. Dollar-Quoted String Constants</h4></div></div></div><a id="id-1.5.3.5.9.7.2" class="indexterm"></a><p>

  346.      While the standard syntax for specifying string constants is usually

  347.      convenient, it can be difficult to understand when the desired string

  348.      contains many single quotes or backslashes, since each of those must

  349.      be doubled. To allow more readable queries in such situations,

  350.      <span class="productname">PostgreSQL</span> provides another way, called

  351.      <span class="quote">“<span class="quote">dollar quoting</span>”</span>, to write string constants.

  352.      A dollar-quoted string constant

  353.      consists of a dollar sign (<code class="literal">$</code>), an optional

  354.      <span class="quote">“<span class="quote">tag</span>”</span> of zero or more characters, another dollar

  355.      sign, an arbitrary sequence of characters that makes up the

  356.      string content, a dollar sign, the same tag that began this

  357.      dollar quote, and a dollar sign. For example, here are two

  358.      different ways to specify the string <span class="quote">“<span class="quote">Dianne's horse</span>”</span>

  359.      using dollar quoting:

  360. </p><pre class="programlisting">

  361. $$Dianne's horse$$

  362. $SomeTag$Dianne's horse$SomeTag$

  363. </pre><p>

  364.      Notice that inside the dollar-quoted string, single quotes can be

  365.      used without needing to be escaped.  Indeed, no characters inside

  366.      a dollar-quoted string are ever escaped: the string content is always

  367.      written literally.  Backslashes are not special, and neither are

  368.      dollar signs, unless they are part of a sequence matching the opening

  369.      tag.

  370.     </p><p>

  371.      It is possible to nest dollar-quoted string constants by choosing

  372.      different tags at each nesting level.  This is most commonly used in

  373.      writing function definitions.  For example:

  374. </p><pre class="programlisting">

  375. $function$

  376. BEGIN

  377.     RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);

  378. END;

  379. $function$

  380. </pre><p>

  381.      Here, the sequence <code class="literal">$q$[\t\r\n\v\\]$q$</code> represents a

  382.      dollar-quoted literal string <code class="literal">[\t\r\n\v\\]</code>, which will

  383.      be recognized when the function body is executed by

  384.      <span class="productname">PostgreSQL</span>.  But since the sequence does not match

  385.      the outer dollar quoting delimiter <code class="literal">$function$</code>, it is

  386.      just some more characters within the constant so far as the outer

  387.      string is concerned.

  388.     </p><p>

  389.      The tag, if any, of a dollar-quoted string follows the same rules

  390.      as an unquoted identifier, except that it cannot contain a dollar sign.

  391.      Tags are case sensitive, so <code class="literal">$tag$String content$tag$</code>

  392.      is correct, but <code class="literal">$TAG$String content$tag$</code> is not.

  393.     </p><p>

  394.      A dollar-quoted string that follows a keyword or identifier must

  395.      be separated from it by whitespace; otherwise the dollar quoting

  396.      delimiter would be taken as part of the preceding identifier.

  397.     </p><p>

  398.      Dollar quoting is not part of the SQL standard, but it is often a more

  399.      convenient way to write complicated string literals than the

  400.      standard-compliant single quote syntax.  It is particularly useful when

  401.      representing string constants inside other constants, as is often needed

  402.      in procedural function definitions.  With single-quote syntax, each

  403.      backslash in the above example would have to be written as four

  404.      backslashes, which would be reduced to two backslashes in parsing the

  405.      original string constant, and then to one when the inner string constant

  406.      is re-parsed during function execution.

  407.     </p></div><div class="sect3" id="SQL-SYNTAX-BIT-STRINGS"><div class="titlepage"><div><div><h4 class="title">4.1.2.5. Bit-String Constants</h4></div></div></div><a id="id-1.5.3.5.9.8.2" class="indexterm"></a><p>

  408.      Bit-string constants look like regular string constants with a

  409.      <code class="literal">B</code> (upper or lower case) immediately before the

  410.      opening quote (no intervening whitespace), e.g.,

  411.      <code class="literal">B'1001'</code>.  The only characters allowed within

  412.      bit-string constants are <code class="literal">0</code> and

  413.      <code class="literal">1</code>.

  414.     </p><p>

  415.      Alternatively, bit-string constants can be specified in hexadecimal

  416.      notation, using a leading <code class="literal">X</code> (upper or lower case),

  417.      e.g., <code class="literal">X'1FF'</code>.  This notation is equivalent to

  418.      a bit-string constant with four binary digits for each hexadecimal digit.

  419.     </p><p>

  420.      Both forms of bit-string constant can be continued

  421.      across lines in the same way as regular string constants.

  422.      Dollar quoting cannot be used in a bit-string constant.

  423.     </p></div><div class="sect3" id="SQL-SYNTAX-CONSTANTS-NUMERIC"><div class="titlepage"><div><div><h4 class="title">4.1.2.6. Numeric Constants</h4></div></div></div><a id="id-1.5.3.5.9.9.2" class="indexterm"></a><p>

  424.      Numeric constants are accepted in these general forms:

  425. </p><pre class="synopsis">

  426. <em class="replaceable"><code>digits</code></em>

  427. <em class="replaceable"><code>digits</code></em>.[<span class="optional"><em class="replaceable"><code>digits</code></em></span>][<span class="optional">e[<span class="optional">+-</span>]<em class="replaceable"><code>digits</code></em></span>]

  428. [<span class="optional"><em class="replaceable"><code>digits</code></em></span>].<em class="replaceable"><code>digits</code></em>[<span class="optional">e[<span class="optional">+-</span>]<em class="replaceable"><code>digits</code></em></span>]

  429. <em class="replaceable"><code>digits</code></em>e[<span class="optional">+-</span>]<em class="replaceable"><code>digits</code></em>

  430. </pre><p>

  431.      where <em class="replaceable"><code>digits</code></em> is one or more decimal

  432.      digits (0 through 9).  At least one digit must be before or after the

  433.      decimal point, if one is used.  At least one digit must follow the

  434.      exponent marker (<code class="literal">e</code>), if one is present.

  435.      There cannot be any spaces or other characters embedded in the

  436.      constant.  Note that any leading plus or minus sign is not actually

  437.      considered part of the constant; it is an operator applied to the

  438.      constant.

  439.     </p><p>

  440.      These are some examples of valid numeric constants:

  441. </p><div class="literallayout"><p><br />

  442. 42<br />

  443. 3.5<br />

  444. 4.<br />

  445. .001<br />

  446. 5e2<br />

  447. 1.925e-3<br />

  448. </p></div><p>

  449.     </p><p>

  450.      <a id="id-1.5.3.5.9.9.5.1" class="indexterm"></a>

  451.      <a id="id-1.5.3.5.9.9.5.2" class="indexterm"></a>

  452.      <a id="id-1.5.3.5.9.9.5.3" class="indexterm"></a>

  453.      A numeric constant that contains neither a decimal point nor an

  454.      exponent is initially presumed to be type <code class="type">integer</code> if its

  455.      value fits in type <code class="type">integer</code> (32 bits); otherwise it is

  456.      presumed to be type <code class="type">bigint</code> if its

  457.      value fits in type <code class="type">bigint</code> (64 bits); otherwise it is

  458.      taken to be type <code class="type">numeric</code>.  Constants that contain decimal

  459.      points and/or exponents are always initially presumed to be type

  460.      <code class="type">numeric</code>.

  461.     </p><p>

  462.      The initially assigned data type of a numeric constant is just a

  463.      starting point for the type resolution algorithms.  In most cases

  464.      the constant will be automatically coerced to the most

  465.      appropriate type depending on context.  When necessary, you can

  466.      force a numeric value to be interpreted as a specific data type

  467.      by casting it.<a id="id-1.5.3.5.9.9.6.1" class="indexterm"></a>

  468.      For example, you can force a numeric value to be treated as type

  469.      <code class="type">real</code> (<code class="type">float4</code>) by writing:

  470. 

  471. </p><pre class="programlisting">

  472. REAL '1.23'  -- string style

  473. 1.23::REAL   -- PostgreSQL (historical) style

  474. </pre><p>

  475. 

  476.      These are actually just special cases of the general casting

  477.      notations discussed next.

  478.     </p></div><div class="sect3" id="SQL-SYNTAX-CONSTANTS-GENERIC"><div class="titlepage"><div><div><h4 class="title">4.1.2.7. Constants of Other Types</h4></div></div></div><a id="id-1.5.3.5.9.10.2" class="indexterm"></a><p>

  479.      A constant of an <span class="emphasis"><em>arbitrary</em></span> type can be

  480.      entered using any one of the following notations:

  481. </p><pre class="synopsis">

  482. <em class="replaceable"><code>type</code></em> '<em class="replaceable"><code>string</code></em>'

  483. '<em class="replaceable"><code>string</code></em>'::<em class="replaceable"><code>type</code></em>

  484. CAST ( '<em class="replaceable"><code>string</code></em>' AS <em class="replaceable"><code>type</code></em> )

  485. </pre><p>

  486.      The string constant's text is passed to the input conversion

  487.      routine for the type called <em class="replaceable"><code>type</code></em>. The

  488.      result is a constant of the indicated type.  The explicit type

  489.      cast can be omitted if there is no ambiguity as to the type the

  490.      constant must be (for example, when it is assigned directly to a

  491.      table column), in which case it is automatically coerced.

  492.     </p><p>

  493.      The string constant can be written using either regular SQL

  494.      notation or dollar-quoting.

  495.     </p><p>

  496.      It is also possible to specify a type coercion using a function-like

  497.      syntax:

  498. </p><pre class="synopsis">

  499. <em class="replaceable"><code>typename</code></em> ( '<em class="replaceable"><code>string</code></em>' )

  500. </pre><p>

  501.      but not all type names can be used in this way; see <a class="xref" href="sql-expressions.html#SQL-SYNTAX-TYPE-CASTS" title="4.2.9. Type Casts">Section 4.2.9</a> for details.

  502.     </p><p>

  503.      The <code class="literal">::</code>, <code class="literal">CAST()</code>, and

  504.      function-call syntaxes can also be used to specify run-time type

  505.      conversions of arbitrary expressions, as discussed in <a class="xref" href="sql-expressions.html#SQL-SYNTAX-TYPE-CASTS" title="4.2.9. Type Casts">Section 4.2.9</a>.  To avoid syntactic ambiguity, the

  506.      <code class="literal"><em class="replaceable"><code>type</code></em> '<em class="replaceable"><code>string</code></em>'</code>

  507.      syntax can only be used to specify the type of a simple literal constant.

  508.      Another restriction on the

  509.      <code class="literal"><em class="replaceable"><code>type</code></em> '<em class="replaceable"><code>string</code></em>'</code>

  510.      syntax is that it does not work for array types; use <code class="literal">::</code>

  511.      or <code class="literal">CAST()</code> to specify the type of an array constant.

  512.     </p><p>

  513.      The <code class="literal">CAST()</code> syntax conforms to SQL.  The

  514.      <code class="literal"><em class="replaceable"><code>type</code></em> '<em class="replaceable"><code>string</code></em>'</code>

  515.      syntax is a generalization of the standard: SQL specifies this syntax only

  516.      for a few data types, but <span class="productname">PostgreSQL</span> allows it

  517.      for all types.  The syntax with

  518.      <code class="literal">::</code> is historical <span class="productname">PostgreSQL</span>

  519.      usage, as is the function-call syntax.

  520.     </p></div></div><div class="sect2" id="SQL-SYNTAX-OPERATORS"><div class="titlepage"><div><div><h3 class="title">4.1.3. Operators</h3></div></div></div><a id="id-1.5.3.5.10.2" class="indexterm"></a><p>

  521.     An operator name is a sequence of up to <code class="symbol">NAMEDATALEN</code>-1

  522.     (63 by default) characters from the following list:

  523. </p><div class="literallayout"><p><br />

  524. + - * / &lt; &gt; = ~ ! @ # % ^ &amp; | ` ?<br />

  525. </p></div><p>

  526. 

  527.     There are a few restrictions on operator names, however:

  528.     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>

  529.        <code class="literal">--</code> and <code class="literal">/*</code> cannot appear

  530.        anywhere in an operator name, since they will be taken as the

  531.        start of a comment.

  532.       </p></li><li class="listitem"><p>

  533.        A multiple-character operator name cannot end in <code class="literal">+</code> or <code class="literal">-</code>,

  534.        unless the name also contains at least one of these characters:

  535. </p><div class="literallayout"><p><br />

  536. ~ ! @ # % ^ &amp; | ` ?<br />

  537. </p></div><p>

  538.        For example, <code class="literal">@-</code> is an allowed operator name,

  539.        but <code class="literal">*-</code> is not.  This restriction allows

  540.        <span class="productname">PostgreSQL</span> to parse SQL-compliant

  541.        queries without requiring spaces between tokens.

  542.       </p></li></ul></div><p>

  543.    </p><p>

  544.     When working with non-SQL-standard operator names, you will usually

  545.     need to separate adjacent operators with spaces to avoid ambiguity.

  546.     For example, if you have defined a left unary operator named <code class="literal">@</code>,

  547.     you cannot write <code class="literal">X*@Y</code>; you must write

  548.     <code class="literal">X* @Y</code> to ensure that

  549.     <span class="productname">PostgreSQL</span> reads it as two operator names

  550.     not one.

  551.    </p></div><div class="sect2" id="SQL-SYNTAX-SPECIAL-CHARS"><div class="titlepage"><div><div><h3 class="title">4.1.4. Special Characters</h3></div></div></div><p>

  552.    Some characters that are not alphanumeric have a special meaning

  553.    that is different from being an operator.  Details on the usage can

  554.    be found at the location where the respective syntax element is

  555.    described.  This section only exists to advise the existence and

  556.    summarize the purposes of these characters.

  557. 

  558.    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>

  559.       A dollar sign (<code class="literal">$</code>) followed by digits is used

  560.       to represent a positional parameter in the body of a function

  561.       definition or a prepared statement.  In other contexts the

  562.       dollar sign can be part of an identifier or a dollar-quoted string

  563.       constant.

  564.      </p></li><li class="listitem"><p>

  565.       Parentheses (<code class="literal">()</code>) have their usual meaning to

  566.       group expressions and enforce precedence.  In some cases

  567.       parentheses are required as part of the fixed syntax of a

  568.       particular SQL command.

  569.      </p></li><li class="listitem"><p>

  570.       Brackets (<code class="literal">[]</code>) are used to select the elements

  571.       of an array.  See <a class="xref" href="arrays.html" title="8.15. Arrays">Section 8.15</a> for more information

  572.       on arrays.

  573.      </p></li><li class="listitem"><p>

  574.       Commas (<code class="literal">,</code>) are used in some syntactical

  575.       constructs to separate the elements of a list.

  576.      </p></li><li class="listitem"><p>

  577.       The semicolon (<code class="literal">;</code>) terminates an SQL command.

  578.       It cannot appear anywhere within a command, except within a

  579.       string constant or quoted identifier.

  580.      </p></li><li class="listitem"><p>

  581.       The colon (<code class="literal">:</code>) is used to select

  582.       <span class="quote">“<span class="quote">slices</span>”</span> from arrays. (See <a class="xref" href="arrays.html" title="8.15. Arrays">Section 8.15</a>.)  In certain SQL dialects (such as Embedded

  583.       SQL), the colon is used to prefix variable names.

  584.      </p></li><li class="listitem"><p>

  585.       The asterisk (<code class="literal">*</code>) is used in some contexts to denote

  586.       all the fields of a table row or composite value.  It also

  587.       has a special meaning when used as the argument of an

  588.       aggregate function, namely that the aggregate does not require

  589.       any explicit parameter.

  590.      </p></li><li class="listitem"><p>

  591.       The period (<code class="literal">.</code>) is used in numeric

  592.       constants, and to separate schema, table, and column names.

  593.      </p></li></ul></div><p>

  594. 

  595.    </p></div><div class="sect2" id="SQL-SYNTAX-COMMENTS"><div class="titlepage"><div><div><h3 class="title">4.1.5. Comments</h3></div></div></div><a id="id-1.5.3.5.12.2" class="indexterm"></a><p>

  596.     A comment is a sequence of characters beginning with

  597.     double dashes and extending to the end of the line, e.g.:

  598. </p><pre class="programlisting">

  599. -- This is a standard SQL comment

  600. </pre><p>

  601.    </p><p>

  602.     Alternatively, C-style block comments can be used:

  603. </p><pre class="programlisting">

  604. /* multiline comment

  605.  * with nesting: /* nested block comment */

  606.  */

  607. </pre><p>

  608.     where the comment begins with <code class="literal">/*</code> and extends to

  609.     the matching occurrence of <code class="literal">*/</code>. These block

  610.     comments nest, as specified in the SQL standard but unlike C, so that one can

  611.     comment out larger blocks of code that might contain existing block

  612.     comments.

  613.    </p><p>

  614.     A comment is removed from the input stream before further syntax

  615.     analysis and is effectively replaced by whitespace.

  616.    </p></div><div class="sect2" id="SQL-PRECEDENCE"><div class="titlepage"><div><div><h3 class="title">4.1.6. Operator Precedence</h3></div></div></div><a id="id-1.5.3.5.13.2" class="indexterm"></a><p>

  617.     <a class="xref" href="sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE" title="Table 4.2. Operator Precedence (highest to lowest)">Table 4.2</a> shows the precedence and

  618.     associativity of the operators in <span class="productname">PostgreSQL</span>.

  619.     Most operators have the same precedence and are left-associative.

  620.     The precedence and associativity of the operators is hard-wired

  621.     into the parser.

  622.    </p><p>

  623.     You will

  624.     sometimes need to add parentheses when using combinations of

  625.     binary and unary operators.  For instance:

  626. </p><pre class="programlisting">

  627. SELECT 5 ! - 6;

  628. </pre><p>

  629.    will be parsed as:

  630. </p><pre class="programlisting">

  631. SELECT 5 ! (- 6);

  632. </pre><p>

  633.     because the parser has no idea — until it is too late

  634.     — that <code class="token">!</code> is defined as a postfix operator,

  635.     not an infix one.  To get the desired behavior in this case, you

  636.     must write:

  637. </p><pre class="programlisting">

  638. SELECT (5 !) - 6;

  639. </pre><p>

  640.     This is the price one pays for extensibility.

  641.    </p><div class="table" id="SQL-PRECEDENCE-TABLE"><p class="title"><strong>Table 4.2. Operator Precedence (highest to lowest)</strong></p><div class="table-contents"><table class="table" summary="Operator Precedence (highest to lowest)" border="1"><colgroup><col /><col /><col /></colgroup><thead><tr><th>Operator/Element</th><th>Associativity</th><th>Description</th></tr></thead><tbody><tr><td><code class="token">.</code></td><td>left</td><td>table/column name separator</td></tr><tr><td><code class="token">::</code></td><td>left</td><td><span class="productname">PostgreSQL</span>-style typecast</td></tr><tr><td><code class="token">[</code> <code class="token">]</code></td><td>left</td><td>array element selection</td></tr><tr><td><code class="token">+</code> <code class="token">-</code></td><td>right</td><td>unary plus, unary minus</td></tr><tr><td><code class="token">^</code></td><td>left</td><td>exponentiation</td></tr><tr><td><code class="token">*</code> <code class="token">/</code> <code class="token">%</code></td><td>left</td><td>multiplication, division, modulo</td></tr><tr><td><code class="token">+</code> <code class="token">-</code></td><td>left</td><td>addition, subtraction</td></tr><tr><td>(any other operator)</td><td>left</td><td>all other native and user-defined operators</td></tr><tr><td><code class="token">BETWEEN</code> <code class="token">IN</code> <code class="token">LIKE</code> <code class="token">ILIKE</code> <code class="token">SIMILAR</code></td><td> </td><td>range containment, set membership, string matching</td></tr><tr><td><code class="token">&lt;</code> <code class="token">&gt;</code> <code class="token">=</code> <code class="token">&lt;=</code> <code class="token">&gt;=</code> <code class="token">&lt;&gt;</code>

  642. </td><td> </td><td>comparison operators</td></tr><tr><td><code class="token">IS</code> <code class="token">ISNULL</code> <code class="token">NOTNULL</code></td><td> </td><td><code class="literal">IS TRUE</code>, <code class="literal">IS FALSE</code>, <code class="literal">IS

  643.        NULL</code>, <code class="literal">IS DISTINCT FROM</code>, etc</td></tr><tr><td><code class="token">NOT</code></td><td>right</td><td>logical negation</td></tr><tr><td><code class="token">AND</code></td><td>left</td><td>logical conjunction</td></tr><tr><td><code class="token">OR</code></td><td>left</td><td>logical disjunction</td></tr></tbody></table></div></div><br class="table-break" /><p>

  644.     Note that the operator precedence rules also apply to user-defined

  645.     operators that have the same names as the built-in operators

  646.     mentioned above.  For example, if you define a

  647.     <span class="quote">“<span class="quote">+</span>”</span> operator for some custom data type it will have

  648.     the same precedence as the built-in <span class="quote">“<span class="quote">+</span>”</span> operator, no

  649.     matter what yours does.

  650.    </p><p>

  651.     When a schema-qualified operator name is used in the

  652.     <code class="literal">OPERATOR</code> syntax, as for example in:

  653. </p><pre class="programlisting">

  654. SELECT 3 OPERATOR(pg_catalog.+) 4;

  655. </pre><p>

  656.     the <code class="literal">OPERATOR</code> construct is taken to have the default precedence

  657.     shown in <a class="xref" href="sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE" title="Table 4.2. Operator Precedence (highest to lowest)">Table 4.2</a> for

  658.     <span class="quote">“<span class="quote">any other operator</span>”</span>.  This is true no matter

  659.     which specific operator appears inside <code class="literal">OPERATOR()</code>.

  660.    </p><div class="note"><h3 class="title">Note</h3><p>

  661.      <span class="productname">PostgreSQL</span> versions before 9.5 used slightly different

  662.      operator precedence rules.  In particular, <code class="token">&lt;=</code>

  663.      <code class="token">&gt;=</code> and <code class="token">&lt;&gt;</code> used to be treated as

  664.      generic operators; <code class="literal">IS</code> tests used to have higher priority;

  665.      and <code class="literal">NOT BETWEEN</code> and related constructs acted inconsistently,

  666.      being taken in some cases as having the precedence of <code class="literal">NOT</code>

  667.      rather than <code class="literal">BETWEEN</code>.  These rules were changed for better

  668.      compliance with the SQL standard and to reduce confusion from

  669.      inconsistent treatment of logically equivalent constructs.  In most

  670.      cases, these changes will result in no behavioral change, or perhaps

  671.      in <span class="quote">“<span class="quote">no such operator</span>”</span> failures which can be resolved by adding

  672.      parentheses.  However there are corner cases in which a query might

  673.      change behavior without any parsing error being reported.  If you are

  674.      concerned about whether these changes have silently broken something,

  675.      you can test your application with the configuration

  676.      parameter <a class="xref" href="runtime-config-compatible.html#GUC-OPERATOR-PRECEDENCE-WARNING">operator_precedence_warning</a> turned on

  677.      to see if any warnings are logged.

  678.     </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="sql-syntax.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="sql-syntax.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="sql-expressions.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. SQL Syntax </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 4.2. Value Expressions</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1