2000-03-31 05:27:42 +02:00
|
|
|
<!--
|
2001-01-06 12:58:56 +01:00
|
|
|
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.32 2001/01/06 11:58:56 petere Exp $
|
2000-03-31 05:27:42 +02:00
|
|
|
-->
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<chapter id="sql-syntax">
|
|
|
|
<title>SQL Syntax</title>
|
1999-05-12 09:32:47 +02:00
|
|
|
|
|
|
|
<abstract>
|
|
|
|
<para>
|
1999-07-22 17:11:05 +02:00
|
|
|
A description of the general syntax of SQL.
|
1999-05-12 09:32:47 +02:00
|
|
|
</para>
|
|
|
|
</abstract>
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<sect1 id="sql-syntax-lexical">
|
|
|
|
<title>Lexical Structure</title>
|
|
|
|
|
1999-07-22 17:11:05 +02:00
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
SQL input consists of a sequence of
|
|
|
|
<firstterm>commands</firstterm>. A command is composed of a
|
|
|
|
sequence of <firstterm>tokens</firstterm>, which depend on the
|
|
|
|
syntax of the particular command, terminated by a semicolon
|
|
|
|
(<quote>;</quote>). The end of the input stream also terminates a
|
|
|
|
command.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<para>
|
|
|
|
A token can be a <firstterm>key word</firstterm>, an
|
|
|
|
<firstterm>identifier</firstterm>, a <firstterm>quoted
|
|
|
|
identifier</firstterm>, a <firstterm>literal</firstterm> (or
|
|
|
|
constant), or a special character symbol. Tokens are normally
|
|
|
|
separated by whitespace (space, tab, newline), but need not be if
|
|
|
|
there is no ambiguity (which is generally only the case if a
|
|
|
|
special character is adjacent to some other token type).
|
|
|
|
</para>
|
1999-05-12 09:32:47 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<para>
|
|
|
|
Additionally, <firstterm>comments</firstterm> can occur in SQL
|
|
|
|
input. They are not tokens, they are effectively equivalent to
|
|
|
|
whitespace.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<informalexample id="sql-syntax-ex-commands">
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
For example, the following is (lexically) valid SQL input:
|
|
|
|
<programlisting>
|
|
|
|
SELECT * FROM MY_TABLE;
|
|
|
|
UPDATE MY_TABLE SET A = 5;
|
|
|
|
INSERT INTO MY_TABLE VALUES (3, 'hi there');
|
|
|
|
</programlisting>
|
|
|
|
This is a sequence of three commands, one per line (although this
|
|
|
|
is not required; more than one command can be on a line, and
|
|
|
|
commands can be usefully split across lines).
|
1999-05-12 09:32:47 +02:00
|
|
|
</para>
|
2001-01-06 12:58:56 +01:00
|
|
|
</informalexample>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The SQL syntax is not very consistent regarding what tokens
|
|
|
|
identify commands and which are operands or parameters. The first
|
|
|
|
few tokens are generally the command name, so in the above example
|
|
|
|
we would usually speak of a <quote>SELECT</quote>, an
|
|
|
|
<quote>UPDATE</quote>, and an <quote>INSERT</quote> command. But
|
|
|
|
for instance the <command>UPDATE</command> command always requires
|
|
|
|
a <token>SET</token> token to appear in a certain position, and
|
|
|
|
this particular variation of <command>INSERT</command> also
|
|
|
|
requires a <token>VALUES</token> in order to be complete. The
|
|
|
|
precise syntax rules for each command are described in the
|
|
|
|
<citetitle>Reference Manual</citetitle>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<sect2 id="sql-syntax-identifiers">
|
|
|
|
<title>Identifiers and Key Words</title>
|
1999-05-12 09:32:47 +02:00
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
Tokens such as <token>SELECT</token>, <token>UPDATE</token>, or
|
|
|
|
<token>VALUES</token> in the example above are examples of
|
|
|
|
<firstterm>key words</firstterm>, that is, words that have a fixed
|
|
|
|
meaning in the SQL language. The tokens <token>MY_TABLE</token>
|
|
|
|
and <token>A</token> are examples of
|
|
|
|
<firstterm>identifiers</firstterm>. They identify names of
|
|
|
|
tables, columns, or other database objects, depending on the
|
|
|
|
command they are used in. Therefore they are sometimes simply
|
|
|
|
called <quote>names</quote>. Key words and identifiers have the
|
|
|
|
same lexical structure, meaning that one cannot know whether a
|
|
|
|
token is an identifier or a key word without knowing the language.
|
|
|
|
A complete list of key words can be found in <xref
|
|
|
|
linkend="sql-keywords-appendix">.
|
1999-05-12 09:32:47 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
SQL identifiers and key words must begin with a letter
|
|
|
|
(<literal>a</literal>-<literal>z</literal>) or underscore
|
|
|
|
(<literal>_</literal>). Subsequent characters in an identifier or
|
|
|
|
key word can be letters, digits
|
|
|
|
(<literal>0</literal>-<literal>9</literal>), or underscores,
|
|
|
|
although the SQL standard will not define a key word that contains
|
|
|
|
digits or start or ends with an underscore.
|
1999-05-12 09:32:47 +02:00
|
|
|
</para>
|
|
|
|
|
1999-07-22 17:11:05 +02:00
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
The system uses no more than <symbol>NAMEDATALEN</symbol>-1
|
|
|
|
characters of an identifier; longer names can be written in
|
|
|
|
commands, but they will be truncated. By default,
|
|
|
|
<symbol>NAMEDATALEN</symbol> is 32 so the maximum identifier length
|
|
|
|
is 31 (but at the time the system is built,
|
|
|
|
<symbol>NAMEDATALEN</symbol> can be changed in
|
|
|
|
<filename>src/include/postgres_ext.h</filename>).
|
2000-07-14 17:26:21 +02:00
|
|
|
</para>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2000-07-14 17:26:21 +02:00
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
Identifier and key word names are case insensitive. Therefore
|
|
|
|
<programlisting>
|
|
|
|
UPDATE MY_TABLE SET A = 5;
|
|
|
|
</programlisting>
|
|
|
|
can equivalently be written as
|
|
|
|
<programlisting>
|
|
|
|
uPDaTE my_TabLE SeT a = 5;
|
|
|
|
</programlisting>
|
|
|
|
A good convention to adopt is perhaps to write key words in upper
|
|
|
|
case and names in lower case, e.g.,
|
|
|
|
<programlisting>
|
|
|
|
UPDATE my_table SET a = 5;
|
|
|
|
</programlisting>
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
There is a second kind of identifier: the <firstterm>delimited
|
|
|
|
identifier</firstterm> or <firstterm>quoted
|
|
|
|
identifier</firstterm>. It is formed by enclosing an arbitrary
|
|
|
|
sequence of characters in double-quotes
|
|
|
|
(<literal>"</literal>). <!-- " font-lock mania --> A delimited
|
|
|
|
identifier is always an identifier, never a key word. So
|
|
|
|
<literal>"select"</literal> could be used to refer to a column or
|
|
|
|
table named <quote>select</quote>, whereas an unquoted
|
|
|
|
<literal>select</literal> would be taken as part of a command and
|
|
|
|
would therefore provoke a parse error when used where a table or
|
|
|
|
column name is expected. The example can be written with quoted
|
|
|
|
identifiers like so:
|
|
|
|
<programlisting>
|
|
|
|
UPDATE "my_table" SET "a" = 5;
|
|
|
|
</programlisting>
|
1999-09-01 04:37:40 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
Quoted identifiers can contain any character other than a double
|
|
|
|
quote itself. This allows constructing table or column names that
|
|
|
|
would otherwise not be possible, such as ones containing spaces or
|
|
|
|
ampersands. The length limitation still applies.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
2000-03-31 01:42:34 +02:00
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
Quoting an identifier also makes it case-sensitive, whereas
|
|
|
|
unquoted names are always folded to lower case. For example, the
|
|
|
|
identifiers <literal>FOO</literal>, <literal>foo</literal> and
|
|
|
|
<literal>"foo"</literal> are considered the same by
|
|
|
|
<productname>Postgres</productname>, but <literal>"Foo"</literal>
|
|
|
|
and <literal>"FOO"</literal> are different from these three and
|
|
|
|
each other.
|
|
|
|
<footnote>
|
|
|
|
<para>
|
|
|
|
This is incompatible with SQL, where unquoted names are folded to
|
|
|
|
upper case. Thus, <literal>foo</literal> is equivalent to
|
|
|
|
<literal>"FOO"</literal>. If you want to write portable
|
|
|
|
applications you are advised to always quote a particular name or
|
|
|
|
never quote it.
|
|
|
|
</para>
|
|
|
|
</footnote>
|
2000-03-31 01:42:34 +02:00
|
|
|
</para>
|
2001-01-06 12:58:56 +01:00
|
|
|
</sect2>
|
|
|
|
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<sect2 id="sql-syntax-constants">
|
1999-07-22 17:11:05 +02:00
|
|
|
<title>Constants</title>
|
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
There are four kinds of <firstterm>implicitly typed
|
|
|
|
constants</firstterm> in <productname>Postgres</productname>:
|
|
|
|
strings, bit strings, integers, and floating point numbers.
|
|
|
|
Constants can also be specified with explicit types, which can
|
|
|
|
enable more accurate representation and more efficient handling by
|
|
|
|
the system. The implicit constants are described below; explicit
|
1999-09-29 07:22:25 +02:00
|
|
|
constants are discussed afterwards.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<sect3>
|
1999-07-22 17:11:05 +02:00
|
|
|
<title>String Constants</title>
|
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
A string constant in SQL is an arbitrary sequence of characters
|
|
|
|
bounded by single quotes (<quote>'</quote>), e.g., <literal>'This
|
|
|
|
is a string'</literal>. SQL allows single quotes to be embedded
|
|
|
|
in strings by typing two adjacent single quotes (e.g.,
|
|
|
|
<literal>'Dianne''s horse'</literal>). In
|
|
|
|
<productname>Postgres</productname> single quotes may
|
|
|
|
alternatively be escaped with a backslash (<quote>\</quote>,
|
|
|
|
e.g., <literal>'Dianne\'s horse'</literal>).
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
C-style backslash escapes are also available:
|
|
|
|
<literal>\b</literal> is a backspace, <literal>\f</literal> is a
|
|
|
|
form feed, <literal>\n</literal> is a newline,
|
|
|
|
<literal>\r</literal> is a carriage return, <literal>\t</literal>
|
|
|
|
is a tab, and <literal>\<replaceable>xxx</replaceable></literal>,
|
|
|
|
where <replaceable>xxx</replaceable> is an octal number, is the
|
|
|
|
character with the corresponding ASCII code. Any other character
|
|
|
|
following a backslash is taken literally. Thus, to include a
|
2000-01-25 08:04:04 +01:00
|
|
|
backslash in a string constant, type two backslashes.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<para>
|
|
|
|
The character with the code zero cannot be in a string constant.
|
|
|
|
</para>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<para>
|
|
|
|
Two string constants that are only separated by whitespace
|
|
|
|
<emphasis>with at least one newline</emphasis> are concatenated
|
|
|
|
and effectively treated as if the string had been written in one
|
|
|
|
constant. For example:
|
|
|
|
<programlisting>
|
|
|
|
SELECT 'foo'
|
|
|
|
'bar';
|
|
|
|
</programlisting>
|
|
|
|
is equivalent to
|
|
|
|
<programlisting>
|
|
|
|
SELECT 'foobar';
|
|
|
|
</programlisting>
|
|
|
|
but
|
|
|
|
<programlisting>
|
|
|
|
SELECT 'foo' 'bar';
|
|
|
|
</programlisting>
|
|
|
|
is not valid syntax.
|
|
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
<title>Bit String Constants</title>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
Bit string constants look like string constants with a
|
|
|
|
<literal>B</literal> (upper or lower case) immediately before the
|
|
|
|
opening quote (no intervening whitespace), e.g.,
|
|
|
|
<literal>B'1001'</literal>. The only characters allowed within
|
|
|
|
bit string constants are <literal>0</literal> and
|
|
|
|
<literal>1</literal>. Bit strings constants can be continued
|
|
|
|
across lines in the same way as regular string constants.
|
1999-09-01 04:37:40 +02:00
|
|
|
</para>
|
2001-01-06 12:58:56 +01:00
|
|
|
</sect3>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<sect3>
|
|
|
|
<title>Integer Constants</title>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
Integer constants in SQL are sequences of decimal digits (0
|
|
|
|
though 9) with no decimal point. The range of legal values
|
|
|
|
depends on which integer data type is used, but the plain
|
|
|
|
<type>integer</type> type accepts values ranging from -2147483648
|
|
|
|
to +2147483647. (The optional plus or minus sign is actually a
|
|
|
|
separate unary operator and not part of the integer constant.)
|
|
|
|
</para>
|
|
|
|
</sect3>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<sect3>
|
|
|
|
<title>Floating Point Constants</title>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<para>
|
|
|
|
Floating point constants are accepted in these general forms:
|
|
|
|
<synopsis>
|
|
|
|
<replaceable>digits</replaceable>.<optional><replaceable>digits</replaceable></optional><optional>e<optional>+-</optional><replaceable>digits</replaceable></optional>
|
|
|
|
<optional><replaceable>digits</replaceable></optional>.<replaceable>digits</replaceable><optional>e<optional>+-</optional><replaceable>digits</replaceable></optional>
|
|
|
|
<replaceable>digits</replaceable>e<optional>+-</optional><replaceable>digits</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
where <replaceable>digits</replaceable> is one or more decimal
|
|
|
|
digits. At least one digit must be before or after the decimal
|
|
|
|
point and after the <literal>e</literal> if you use that option.
|
|
|
|
Thus, a floating point constant is distinguished from an integer
|
|
|
|
constant by the presence of either the decimal point or the
|
|
|
|
exponent clause (or both). There must not be a space or other
|
|
|
|
characters embedded in the constant.
|
1999-09-01 04:37:40 +02:00
|
|
|
</para>
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<informalexample>
|
|
|
|
<para>
|
|
|
|
These are some examples of valid floating point constants:
|
|
|
|
<literallayout>
|
|
|
|
3.5
|
|
|
|
4.
|
|
|
|
.001
|
|
|
|
5e2
|
|
|
|
1.925e-3
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</informalexample>
|
|
|
|
|
1999-09-01 04:37:40 +02:00
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
Floating point constants are of type <type>DOUBLE
|
|
|
|
PRECISION</type>. <type>REAL</type> can be specified explicitly
|
|
|
|
by using <acronym>SQL</acronym> string notation or
|
1999-09-01 04:37:40 +02:00
|
|
|
<productname>Postgres</productname> type notation:
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<programlisting>
|
|
|
|
REAL '1.23' -- string style
|
|
|
|
'1.23'::REAL -- Postgres (historical) style
|
1999-09-01 04:37:40 +02:00
|
|
|
</programlisting>
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
2001-01-06 12:58:56 +01:00
|
|
|
</sect3>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<sect3>
|
|
|
|
<title>Constants of Other Types</title>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
A constant of an <emphasis>arbitrary</emphasis> type can be
|
|
|
|
entered using any one of the following notations:
|
|
|
|
<synopsis>
|
1999-07-22 17:11:05 +02:00
|
|
|
<replaceable>type</replaceable> '<replaceable>string</replaceable>'
|
|
|
|
'<replaceable>string</replaceable>'::<replaceable>type</replaceable>
|
2000-08-07 21:53:27 +02:00
|
|
|
CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
2001-01-06 12:58:56 +01:00
|
|
|
</synopsis>
|
|
|
|
The value inside the string is passed to the input conversion
|
|
|
|
routine for the type called <replaceable>type</replaceable>. The
|
|
|
|
result is a constant of the indicated type. The explicit type
|
|
|
|
cast may be omitted if there is no ambiguity as to the type the
|
|
|
|
constant must be (for example, when it is passed as an argument
|
|
|
|
to a non-overloaded function), in which case it is automatically
|
|
|
|
coerced.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
2000-12-17 06:47:57 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
It is also possible to specify a type coercion using a function-like
|
|
|
|
syntax:
|
2001-01-06 12:58:56 +01:00
|
|
|
<synopsis>
|
2000-12-17 06:47:57 +01:00
|
|
|
<replaceable>typename</replaceable> ( <replaceable>value</replaceable> )
|
2001-01-06 12:58:56 +01:00
|
|
|
</synopsis>
|
2000-12-17 06:47:57 +01:00
|
|
|
although this only works for types whose names are also valid as
|
|
|
|
function names. (For example, <literal>double precision</literal>
|
|
|
|
can't be used this way --- but the equivalent <literal>float8</literal>
|
|
|
|
can.)
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2001-01-06 12:58:56 +01:00
|
|
|
The <literal>::</literal>, <literal>CAST()</literal>, and
|
|
|
|
function-call syntaxes can also be used to specify the type of
|
|
|
|
arbitrary expressions, but the form
|
|
|
|
<replaceable>type</replaceable>
|
|
|
|
'<replaceable>string</replaceable>' can only be used to specify
|
|
|
|
the type of a literal constant.
|
2000-12-17 06:47:57 +01:00
|
|
|
</para>
|
2001-01-06 12:58:56 +01:00
|
|
|
</sect3>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<sect3>
|
1999-07-22 17:11:05 +02:00
|
|
|
<title>Array constants</title>
|
|
|
|
|
|
|
|
<para>
|
2000-12-17 06:47:57 +01:00
|
|
|
The general format of an array constant is the following:
|
2001-01-06 12:58:56 +01:00
|
|
|
<synopsis>
|
|
|
|
'{ <replaceable>val1</replaceable> <replaceable>delim</replaceable> <replaceable>val2</replaceable> <replaceable>delim</replaceable> ... }'
|
|
|
|
</synopsis>
|
|
|
|
where <replaceable>delim</replaceable> is the delimiter character
|
|
|
|
for the type, as recorded in its <literal>pg_type</literal>
|
|
|
|
entry. (For all built-in types, this is the comma character
|
|
|
|
",".) Each <replaceable>val</replaceable> is either a constant
|
|
|
|
of the array element type, or a sub-array. An example of an
|
|
|
|
array constant is
|
|
|
|
<programlisting>
|
|
|
|
'{{1,2,3},{4,5,6},{7,8,9}}'
|
|
|
|
</programlisting>
|
1999-07-22 17:11:05 +02:00
|
|
|
This constant is a two-dimensional, 3 by 3 array consisting of three
|
|
|
|
sub-arrays of integers.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-12-19 00:39:37 +01:00
|
|
|
Individual array elements can be placed between double-quote
|
2001-01-06 12:58:56 +01:00
|
|
|
marks (<literal>"</literal>) <!-- " --> to avoid ambiguity
|
|
|
|
problems with respect to white space. Without quote marks, the
|
|
|
|
array-value parser will skip leading white space.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
|
2001-01-06 12:58:56 +01:00
|
|
|
<para>
|
|
|
|
(Array constants are actually only a special case of the generic
|
|
|
|
type constants discussed in the previous section. The constant
|
|
|
|
is initially treated as a string and passed to the array input
|
|
|
|
conversion routine. An explicit type specification might be
|
|
|
|
necessary.)
|
|
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
|
|
<sect2 id="sql-syntax-operators">
|
|
|
|
<title>Operators</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
An operator is a sequence of up to <symbol>NAMEDATALEN</symbol>-1
|
|
|
|
(31 by default) characters from the following list:
|
|
|
|
<literallayout>
|
|
|
|
+ - * / < > = ~ ! @ # % ^ & | ` ? $
|
|
|
|
</literallayout>
|
|
|
|
|
|
|
|
There are a few restrictions on operator names, however:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
"$" (dollar) cannot be a single-character operator, although it
|
|
|
|
can be part of a multi-character operator name.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
<literal>--</literal> and <literal>/*</literal> cannot appear
|
|
|
|
anywhere in an operator name, since they will be taken as the
|
|
|
|
start of a comment.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A multi-character operator name cannot end in "+" or "-",
|
|
|
|
unless the name also contains at least one of these characters:
|
|
|
|
<literallayout>
|
|
|
|
~ ! @ # % ^ & | ` ? $
|
|
|
|
</literallayout>
|
|
|
|
For example, <literal>@-</literal> is an allowed operator name,
|
|
|
|
but <literal>*-</literal> is not. This restriction allows
|
|
|
|
<productname>Postgres</productname> to parse SQL-compliant
|
|
|
|
queries without requiring spaces between tokens.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
When working with non-SQL-standard operator names, you will usually
|
|
|
|
need to separate adjacent operators with spaces to avoid ambiguity.
|
|
|
|
For example, if you have defined a left-unary operator named "@",
|
|
|
|
you cannot write <literal>X*@Y</literal>; you must write
|
|
|
|
<literal>X* @Y</literal> to ensure that
|
|
|
|
<productname>Postgres</productname> reads it as two operator names
|
|
|
|
not one.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Special Characters</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Some characters that are not alphanumeric have a special meaning
|
|
|
|
that is different from being an operator. Details on the usage can
|
|
|
|
be found at the location where the respective syntax element is
|
|
|
|
described. This section only exists to advise the existence and
|
|
|
|
summarize the purposes of these characters.
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A dollar sign (<literal>$</literal>) followed by digits is used
|
|
|
|
to represent the positional parameters in the body of a function
|
|
|
|
definition. In other contexts the dollar sign may be part of an
|
|
|
|
operator name.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Parentheses (<literal>()</literal>) have their usual meaning to
|
|
|
|
group expressions and enforce precedence. In some cases
|
|
|
|
parentheses are required as part of the fixed syntax of a
|
|
|
|
particular SQL command.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Brackets (<literal>[]</literal>) are used to select the elements
|
|
|
|
of an array. See <xref linkend="arrays"> for more information
|
|
|
|
on arrays.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Commas (<literal>,</literal>) are used in some syntactical
|
|
|
|
constructs to separate the elements of a list.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The semicolon (<literal>;</literal>) terminates an SQL command.
|
|
|
|
It cannot appear anywhere within a command, except when quoted
|
|
|
|
as a string constant or identifier.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The colon (<literal>:</literal>) is used to select
|
|
|
|
<quote>slices</quote> from arrays. (See <xref
|
|
|
|
linkend="arrays">.) In certain SQL dialects (such as Embedded
|
|
|
|
SQL), the colon is used to prefix variable names.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The asterisk (<literal>*</literal>) has a special meaning when
|
|
|
|
used in the <command>SELECT</command> command or with the
|
|
|
|
<function>COUNT</function> aggregate function.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The period (<literal>.</literal>) is used in floating point
|
|
|
|
constants, and to separate table and column names.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="sql-syntax-comments">
|
|
|
|
<title>Comments</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A comment is an arbitrary sequence of characters beginning with
|
|
|
|
double dashes and extending to the end of the line, e.g.:
|
|
|
|
<programlisting>
|
|
|
|
-- This is a standard SQL92 comment
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Alternatively, C-style block comments can be used:
|
|
|
|
<programlisting>
|
|
|
|
/* multi-line comment
|
|
|
|
* with nesting: /* nested block comment */
|
|
|
|
*/
|
|
|
|
</programlisting>
|
|
|
|
where the comment begins with <literal>/*</literal> and extends to
|
|
|
|
the matching occurrence of <literal>*/</literal>. These block
|
|
|
|
comments nest, as specified in SQL99 but unlike C, so that one can
|
|
|
|
comment out larger blocks of code that may contain existing block
|
|
|
|
comments.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A comment is removed from the input stream before further syntax
|
|
|
|
analysis and is effectively replaced by whitespace.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
|
<sect1 id="sql-syntax-columns">
|
1999-07-22 17:11:05 +02:00
|
|
|
<title>Fields and Columns</title>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Fields</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A <firstterm>field</firstterm>
|
2000-12-17 06:47:57 +01:00
|
|
|
is either a user-defined attribute of a given class or one of the
|
|
|
|
following system-defined attributes:
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term>oid</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
stands for the unique identifier of an instance which is added by
|
2000-12-17 06:47:57 +01:00
|
|
|
Postgres to all instances automatically. OIDs are not reused and are
|
|
|
|
32-bit quantities.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term>xmin</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The identity of the inserting transaction.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term>xmax</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The identity of the deleting transaction.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term>cmin</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2000-12-17 06:47:57 +01:00
|
|
|
The command identifier within the inserting transaction.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term>cmax</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2000-12-17 06:47:57 +01:00
|
|
|
The command identifier within the deleting transaction.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-12-17 06:47:57 +01:00
|
|
|
For further information on the system attributes consult
|
1999-07-22 17:11:05 +02:00
|
|
|
<xref linkend="STON87a" endterm="STON87a">.
|
2000-12-17 06:47:57 +01:00
|
|
|
Transaction and command identifiers are 32 bit quantities.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Columns</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A <firstterm>column</firstterm> is a construct of the form:
|
|
|
|
|
|
|
|
<synopsis>
|
2000-12-17 06:47:57 +01:00
|
|
|
<replaceable>instance</replaceable>{.<replaceable>composite_field</replaceable>}.<replaceable>field</replaceable> `['<replaceable>subscript</replaceable>`]'
|
1999-07-22 17:11:05 +02:00
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
<replaceable>instance</replaceable>
|
|
|
|
identifies a particular class and can be thought of as standing for
|
|
|
|
the instances of that class. An instance variable is either a class
|
2000-12-17 06:47:57 +01:00
|
|
|
name, an alias for a class defined by means of a FROM clause,
|
|
|
|
or the keyword NEW or OLD.
|
|
|
|
(NEW and OLD can only appear in the action portion of a rule, while
|
|
|
|
other instance variables can be used in any SQL statement.) The
|
|
|
|
instance name can be omitted if the first field name is unique
|
|
|
|
across all the classes being used in the current query.
|
1999-07-22 17:11:05 +02:00
|
|
|
<replaceable>composite_field</replaceable>
|
|
|
|
is a field of of one of the Postgres composite types,
|
2000-12-17 06:47:57 +01:00
|
|
|
while successive composite fields select attributes in the
|
1999-07-22 17:11:05 +02:00
|
|
|
class(s) to which the composite field evaluates. Lastly,
|
|
|
|
<replaceable>field</replaceable>
|
|
|
|
is a normal (base type) field in the class(s) last addressed. If
|
|
|
|
<replaceable>field</replaceable>
|
2000-12-17 06:47:57 +01:00
|
|
|
is of an array type,
|
|
|
|
then the optional <replaceable>subscript</replaceable>
|
|
|
|
selects a specific element in the array. If no subscript is
|
|
|
|
provided, then the whole array is selected.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="sql-expressions">
|
1999-05-12 09:32:47 +02:00
|
|
|
<title>Expressions</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<acronym>SQL92</acronym> allows <firstterm>expressions</firstterm>
|
1999-07-22 17:11:05 +02:00
|
|
|
to transform data in tables. Expressions may contain operators
|
2000-12-14 23:30:56 +01:00
|
|
|
and functions.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
1999-05-12 09:32:47 +02:00
|
|
|
|
1999-07-22 17:11:05 +02:00
|
|
|
<para>
|
|
|
|
An expression is one of the following:
|
|
|
|
|
|
|
|
<simplelist>
|
|
|
|
<member>constant</member>
|
2000-12-17 06:47:57 +01:00
|
|
|
<member>column</member>
|
|
|
|
<member><replaceable>expression</replaceable> <replaceable>binary_operator</replaceable> <replaceable>expression</replaceable></member>
|
|
|
|
<member><replaceable>expression</replaceable> <replaceable>right_unary_operator</replaceable></member>
|
|
|
|
<member><replaceable>left_unary_operator</replaceable> <replaceable>expression</replaceable></member>
|
|
|
|
<member>( <replaceable>expression</replaceable> )</member>
|
1999-07-22 17:11:05 +02:00
|
|
|
<member>parameter</member>
|
1999-12-13 18:39:38 +01:00
|
|
|
<member>functional expression</member>
|
|
|
|
<member>aggregate expression</member>
|
1999-07-22 17:11:05 +02:00
|
|
|
</simplelist>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-12-17 06:47:57 +01:00
|
|
|
We have already discussed constants and columns. The three kinds of
|
1999-12-13 18:39:38 +01:00
|
|
|
operator expressions indicate respectively binary (infix), right-unary
|
|
|
|
(suffix) and left-unary (prefix) operators. The following sections
|
|
|
|
discuss the remaining options.
|
1999-05-12 09:32:47 +02:00
|
|
|
</para>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A <firstterm>parameter</firstterm>
|
|
|
|
is used to indicate a parameter in a SQL function. Typically this
|
2000-12-17 06:47:57 +01:00
|
|
|
is used in SQL function definition statements. The form of a
|
1999-07-22 17:11:05 +02:00
|
|
|
parameter is:
|
|
|
|
|
|
|
|
<synopsis>
|
|
|
|
$<replaceable class="parameter">number</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For example, consider the definition of a function,
|
|
|
|
<function>dept</function>, as
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
CREATE FUNCTION dept (name)
|
|
|
|
RETURNS dept
|
2000-12-17 06:47:57 +01:00
|
|
|
AS 'select * from dept where name = $1'
|
1999-07-22 17:11:05 +02:00
|
|
|
LANGUAGE 'sql';
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Functional Expressions</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A <firstterm>functional expression</firstterm>
|
|
|
|
is the name of a legal SQL function, followed by its argument list
|
|
|
|
enclosed in parentheses:
|
|
|
|
|
|
|
|
<synopsis>
|
2000-12-17 06:47:57 +01:00
|
|
|
<replaceable>function</replaceable> (<replaceable>expression</replaceable> [, <replaceable>expression</replaceable> ... ] )
|
1999-07-22 17:11:05 +02:00
|
|
|
</synopsis>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For example, the following computes the square root of an employee
|
|
|
|
salary:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
sqrt(emp.salary)
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
2000-12-14 23:30:56 +01:00
|
|
|
<sect2 id="syntax-aggregates">
|
|
|
|
<title>Aggregate Expressions</title>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<para>
|
1999-12-13 18:39:38 +01:00
|
|
|
An <firstterm>aggregate expression</firstterm> represents the application
|
|
|
|
of an aggregate function across the rows selected by a query.
|
|
|
|
An aggregate function reduces multiple inputs to a single output value,
|
|
|
|
such as the sum or average of the inputs.
|
|
|
|
The syntax of an aggregate expression is one of the following:
|
1999-07-22 17:11:05 +02:00
|
|
|
|
1999-12-13 18:39:38 +01:00
|
|
|
<simplelist>
|
|
|
|
<member><replaceable>aggregate_name</replaceable> (<replaceable>expression</replaceable>)</member>
|
2000-02-21 02:20:41 +01:00
|
|
|
<member><replaceable>aggregate_name</replaceable> (ALL <replaceable>expression</replaceable>)</member>
|
1999-12-13 18:39:38 +01:00
|
|
|
<member><replaceable>aggregate_name</replaceable> (DISTINCT <replaceable>expression</replaceable>)</member>
|
|
|
|
<member><replaceable>aggregate_name</replaceable> ( * )</member>
|
|
|
|
</simplelist>
|
|
|
|
|
|
|
|
where <replaceable>aggregate_name</replaceable> is a previously defined
|
|
|
|
aggregate, and <replaceable>expression</replaceable> is any expression
|
|
|
|
that doesn't itself contain an aggregate expression.
|
|
|
|
</para>
|
1999-07-22 17:11:05 +02:00
|
|
|
|
1999-12-13 18:39:38 +01:00
|
|
|
<para>
|
|
|
|
The first form of aggregate expression invokes the aggregate across all
|
|
|
|
input rows for which the given expression yields a non-null value.
|
2000-02-21 02:20:41 +01:00
|
|
|
The second form is the same as the first, since ALL is the default.
|
|
|
|
The third form invokes the aggregate for all distinct non-null values
|
1999-12-13 18:39:38 +01:00
|
|
|
of the expression found in the input rows. The last form invokes the
|
|
|
|
aggregate once for each input row regardless of null or non-null values;
|
|
|
|
since no particular input value is specified, it is generally only useful
|
|
|
|
for the count() aggregate.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For example, count(*) yields the total number of input rows;
|
|
|
|
count(f1) yields the number of input rows in which f1 is non-null;
|
|
|
|
count(distinct f1) yields the number of distinct non-null values of f1.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Target List</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A <firstterm>target list</firstterm>
|
2000-12-16 19:22:53 +01:00
|
|
|
is a comma-separated list of one or more elements, each
|
1999-07-22 17:11:05 +02:00
|
|
|
of which must be of the form:
|
|
|
|
|
|
|
|
<synopsis>
|
2000-12-17 06:47:57 +01:00
|
|
|
<replaceable>expression</replaceable> [ AS <replaceable>result_attname</replaceable> ]
|
1999-07-22 17:11:05 +02:00
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where <replaceable>result_attname</replaceable>
|
2000-12-16 19:22:53 +01:00
|
|
|
is the name to be assigned to the created column. If
|
1999-07-22 17:11:05 +02:00
|
|
|
<replaceable>result_attname</replaceable>
|
2000-12-16 19:22:53 +01:00
|
|
|
is not present, then <productname>Postgres</productname> selects a
|
2000-12-17 06:47:57 +01:00
|
|
|
default name based on the contents of <replaceable>expression</replaceable>.
|
|
|
|
If <replaceable>expression</replaceable> is a simple attribute reference
|
2000-12-16 19:22:53 +01:00
|
|
|
then the default name will be the same as that attribute's name, but
|
|
|
|
otherwise the implementation is free to assign any default name.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Qualification</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A <firstterm>qualification</firstterm>
|
|
|
|
consists of any number of clauses connected by the logical operators:
|
|
|
|
|
|
|
|
<simplelist>
|
|
|
|
<member>NOT</member>
|
|
|
|
<member>AND</member>
|
|
|
|
<member>OR</member>
|
|
|
|
</simplelist>
|
|
|
|
|
2000-12-17 06:47:57 +01:00
|
|
|
A clause is an <replaceable>expression</replaceable>
|
1999-07-22 17:11:05 +02:00
|
|
|
that evaluates to a <literal>boolean</literal> over a set of instances.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>From List</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The <firstterm>from list</firstterm>
|
2000-12-17 06:47:57 +01:00
|
|
|
is a comma-separated list of <firstterm>from-expressions</firstterm>.
|
|
|
|
The simplest possibility for a from-expression is:
|
|
|
|
|
|
|
|
<synopsis>
|
|
|
|
<replaceable>class_reference</replaceable> [ [ AS ] <replaceable class="PARAMETER">alias</replaceable> ]
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where <replaceable>class_reference</replaceable> is of the form
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<synopsis>
|
2000-12-17 06:47:57 +01:00
|
|
|
[ ONLY ] <replaceable class="PARAMETER">table_name</replaceable> [ * ]
|
1999-07-22 17:11:05 +02:00
|
|
|
</synopsis>
|
|
|
|
|
2000-12-17 06:47:57 +01:00
|
|
|
The from-expression defines an instance variable that ranges over the
|
|
|
|
rows of the specified table. The instance variable's name is either
|
|
|
|
the table name, or the <replaceable>alias</replaceable> if one is given.
|
|
|
|
Ordinarily, if the table has child tables then the instance variable
|
|
|
|
will range over all rows in the inheritance hierarchy starting with
|
|
|
|
the specified table. If <literal>ONLY</literal> is specified then
|
|
|
|
child tables are not included. A trailing asterisk <literal>*</literal>
|
|
|
|
can be written to specifically indicate that child tables are included
|
|
|
|
(<literal>ONLY</literal> and <literal>*</literal> are mutually
|
|
|
|
exclusive).
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A from-expression can also be a sub-query:
|
|
|
|
|
|
|
|
<synopsis>
|
|
|
|
( <replaceable class="PARAMETER">select-statement</replaceable> ) [ AS ] <replaceable class="PARAMETER">alias</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
Here, the effect is as though the SELECT were executed and its results
|
|
|
|
stored in a temporary table, which then becomes available as an instance
|
|
|
|
variable under the given <replaceable>alias</replaceable>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Finally, a from-expression can be built up from simpler from-expressions
|
|
|
|
using JOIN clauses:
|
1999-07-22 17:11:05 +02:00
|
|
|
|
|
|
|
<synopsis>
|
2000-12-17 06:47:57 +01:00
|
|
|
<replaceable class="PARAMETER">from_expression</replaceable> [ NATURAL ] <replaceable class="PARAMETER">join_type</replaceable> <replaceable class="PARAMETER">from_expression</replaceable>
|
|
|
|
[ ON <replaceable class="PARAMETER">join_condition</replaceable> | USING ( <replaceable class="PARAMETER">join_column_list</replaceable> ) ]
|
1999-07-22 17:11:05 +02:00
|
|
|
</synopsis>
|
|
|
|
|
2000-12-17 06:47:57 +01:00
|
|
|
This syntax allows specification of <firstterm>outer joins</firstterm>.
|
|
|
|
For details see the reference page for SELECT.
|
1999-07-22 17:11:05 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
2000-12-14 23:30:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
<sect2 id="sql-precedence">
|
|
|
|
<title>Lexical Precedence</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The precedence and associativity of the operators is hard-wired
|
|
|
|
into the parser. Most operators have the same precedence and are
|
|
|
|
left-associative. This may lead to non-intuitive behavior; for
|
|
|
|
example the boolean operators "<" and ">" have a different
|
|
|
|
precedence than the boolean operators "<=" and ">=". Also,
|
2000-12-17 06:47:57 +01:00
|
|
|
you will sometimes need to add parentheses when using combinations
|
2000-12-14 23:30:56 +01:00
|
|
|
of binary and unary operators. For instance
|
|
|
|
<programlisting>
|
|
|
|
SELECT 5 & ~ 6;
|
|
|
|
</programlisting>
|
|
|
|
will be parsed as
|
|
|
|
<programlisting>
|
|
|
|
SELECT (5 &) ~ 6;
|
|
|
|
</programlisting>
|
|
|
|
because the parser has no idea that <token>&</token> is
|
|
|
|
defined as a binary operator. This is the price one pays for
|
|
|
|
extensibility.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<table tocentry="1">
|
|
|
|
<title>Operator Ordering (decreasing precedence)</title>
|
|
|
|
|
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>OperatorElement</entry>
|
|
|
|
<entry>Associativity</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry><token>::</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry><productname>Postgres</productname>-style typecast</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>[</token> <token>]</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>array element selection</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>.</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>table/column name separator</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>-</token></entry>
|
|
|
|
<entry>right</entry>
|
|
|
|
<entry>unary minus</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>^</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>exponentiation</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>*</token> <token>/</token> <token>%</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>multiplication, division, modulo</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>+</token> <token>-</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>addition, subtraction</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>IS</token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>test for TRUE, FALSE, NULL</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>ISNULL</token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>test for NULL</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>NOTNULL</token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>test for NOT NULL</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry>(any other)</entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>all other native and user-defined operators</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>IN</token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>set membership</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>BETWEEN</token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>containment</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>OVERLAPS</token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>time interval overlap</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>LIKE</token> <token>ILIKE</token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>string pattern matching</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token><</token> <token>></token></entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>less than, greater than</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>=</token></entry>
|
|
|
|
<entry>right</entry>
|
|
|
|
<entry>equality, assignment</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>NOT</token></entry>
|
|
|
|
<entry>right</entry>
|
|
|
|
<entry>logical negation</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>AND</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>logical conjunction</entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry><token>OR</token></entry>
|
|
|
|
<entry>left</entry>
|
|
|
|
<entry>logical disjunction</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Note that the operator precedence rules also apply to user-defined
|
2000-12-17 06:47:57 +01:00
|
|
|
operators that have the same names as the built-in operators
|
|
|
|
mentioned above. For example, if you define a
|
2000-12-14 23:30:56 +01:00
|
|
|
<quote>+</quote> operator for some custom data type it will have
|
|
|
|
the same precedence as the built-in <quote>+</quote> operator, no
|
|
|
|
matter what yours does.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
</sect1>
|
|
|
|
</chapter>
|
1999-04-06 17:41:20 +02:00
|
|
|
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
|
|
Local variables:
|
2000-03-31 05:27:42 +02:00
|
|
|
mode:sgml
|
1999-04-06 17:41:20 +02:00
|
|
|
sgml-omittag:nil
|
|
|
|
sgml-shorttag:t
|
|
|
|
sgml-minimize-attributes:nil
|
|
|
|
sgml-always-quote-attributes:t
|
|
|
|
sgml-indent-step:1
|
|
|
|
sgml-indent-data:t
|
|
|
|
sgml-parent-document:nil
|
|
|
|
sgml-default-dtd-file:"./reference.ced"
|
|
|
|
sgml-exposed-tags:nil
|
2000-03-31 05:27:42 +02:00
|
|
|
sgml-local-catalogs:("/usr/lib/sgml/catalog")
|
1999-04-06 17:41:20 +02:00
|
|
|
sgml-local-ecat-files:nil
|
|
|
|
End:
|
|
|
|
-->
|