Update section on SQL syntax. (Still a lot to be done though.) Add

appendix with comprehensive list of key words.
REL7_1_STABLE
Peter Eisentraut 25 years ago
parent 3ff76734f6
commit 3942ee389c
  1. 4
      doc/src/sgml/datetime.sgml
  2. 3
      doc/src/sgml/filelist.sgml
  3. 3163
      doc/src/sgml/keywords.sgml
  4. 834
      doc/src/sgml/syntax.sgml
  5. 3
      doc/src/sgml/user.sgml

@ -1,9 +1,9 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.15 2000/12/22 21:51:57 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.16 2001/01/06 11:58:55 petere Exp $
Date/time details Date/time details
--> -->
<appendix label="UG1" id="datetime-appendix"> <appendix id="datetime-appendix">
<title id="datetime-appendix-title">Date/Time Support</title> <title id="datetime-appendix-title">Date/Time Support</title>
<sect1 id="timezones"> <sect1 id="timezones">

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.3 2000/12/16 02:29:36 tgl Exp $ --> <!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.4 2001/01/06 11:58:56 petere Exp $ -->
<!entity about SYSTEM "about.sgml"> <!entity about SYSTEM "about.sgml">
<!entity history SYSTEM "history.sgml"> <!entity history SYSTEM "history.sgml">
@ -35,6 +35,7 @@
<!entity storage SYSTEM "storage.sgml"> <!entity storage SYSTEM "storage.sgml">
<!entity syntax SYSTEM "syntax.sgml"> <!entity syntax SYSTEM "syntax.sgml">
<!entity typeconv SYSTEM "typeconv.sgml"> <!entity typeconv SYSTEM "typeconv.sgml">
<!entity keywords SYSTEM "keywords.sgml">
<!-- reference pages --> <!-- reference pages -->
<!entity % allfiles SYSTEM "ref/allfiles.sgml"> <!entity % allfiles SYSTEM "ref/allfiles.sgml">

File diff suppressed because it is too large Load Diff

@ -1,8 +1,8 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.31 2000/12/22 18:57:50 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.32 2001/01/06 11:58:56 petere Exp $
--> -->
<chapter id="syntax"> <chapter id="sql-syntax">
<title>SQL Syntax</title> <title>SQL Syntax</title>
<abstract> <abstract>
@ -11,558 +11,548 @@ $Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.31 2000/12/22 18:57:50 pete
</para> </para>
</abstract> </abstract>
<sect1 id="sql-syntax-lexical">
<title>Lexical Structure</title>
<para> <para>
<acronym>SQL</acronym> manipulates sets of data. The language is SQL input consists of a sequence of
composed of various <firstterm>key words</firstterm>. Arithmetic <firstterm>commands</firstterm>. A command is composed of a
and procedural expressions are allowed. We will cover these topics sequence of <firstterm>tokens</firstterm>, which depend on the
in this chapter; subsequent chapters will include details on data syntax of the particular command, terminated by a semicolon
types, functions, and operators. (<quote>;</quote>). The end of the input stream also terminates a
command.
</para> </para>
<sect1 id="sql-keywords"> <para>
<title>Key Words</title> 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>
<para> <para>
<acronym>SQL92</acronym> defines <firstterm>key words</firstterm> Additionally, <firstterm>comments</firstterm> can occur in SQL
for the language input. They are not tokens, they are effectively equivalent to
which have specific meaning. Some key words are whitespace.
<firstterm>reserved</firstterm>, which indicates that they are
restricted to appear in only certain contexts. Other key words are
<firstterm>not restricted</firstterm>, which indicates that in certain
contexts they
have a specific meaning but are not otherwise constrained.
</para> </para>
<informalexample id="sql-syntax-ex-commands">
<para> <para>
<productname>Postgres</productname> implements an extended subset of the For example, the following is (lexically) valid SQL input:
<acronym>SQL92</acronym> and <acronym>SQL3</acronym> languages. Some language <programlisting>
elements are not as restricted in this implementation as is SELECT * FROM MY_TABLE;
called for in the language standards, in part due UPDATE MY_TABLE SET A = 5;
to the extensibility features of <productname>Postgres</productname>. 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).
</para> </para>
</informalexample>
<para> <para>
Information on <acronym>SQL92</acronym> and <acronym>SQL3</acronym> key words The SQL syntax is not very consistent regarding what tokens
is derived from <xref linkend="DATE97" endterm="DATE97">. 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> </para>
<sect2> <sect2 id="sql-syntax-identifiers">
<title>Reserved Key Words</title> <title>Identifiers and Key Words</title>
<para> <para>
<acronym>SQL92</acronym> and <acronym>SQL3</acronym> have Tokens such as <token>SELECT</token>, <token>UPDATE</token>, or
<firstterm>reserved key words</firstterm> which are not allowed <token>VALUES</token> in the example above are examples of
as identifiers and not allowed in any usage other than as fundamental <firstterm>key words</firstterm>, that is, words that have a fixed
tokens in <acronym>SQL</acronym> statements. meaning in the SQL language. The tokens <token>MY_TABLE</token>
<productname>Postgres</productname> has additional key words and <token>A</token> are examples of
which have similar restrictions. In particular, these key words <firstterm>identifiers</firstterm>. They identify names of
are not allowed as column or table names, though in some cases tables, columns, or other database objects, depending on the
they are allowed to be column labels (i.e. in AS clauses). 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">.
</para> </para>
<tip>
<para> <para>
Any string can be used as an identifier if surrounded by SQL identifiers and key words must begin with a letter
double quotes (<quote>like this!</quote>). Some care is required since (<literal>a</literal>-<literal>z</literal>) or underscore
such an identifier will be case sensitive (<literal>_</literal>). Subsequent characters in an identifier or
and will retain embedded whitespace and most other special characters. 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.
</para> </para>
</tip>
<para> <para>
The following are <productname>Postgres</productname> The system uses no more than <symbol>NAMEDATALEN</symbol>-1
reserved words that are neither <acronym>SQL92</acronym> characters of an identifier; longer names can be written in
nor <acronym>SQL3</acronym> reserved words. These are allowed commands, but they will be truncated. By default,
to be present as column labels, but not as identifiers: <symbol>NAMEDATALEN</symbol> is 32 so the maximum identifier length
is 31 (but at the time the system is built,
<programlisting> <symbol>NAMEDATALEN</symbol> can be changed in
ABORT ANALYZE <filename>src/include/postgres_ext.h</filename>).
BINARY
CLUSTER CONSTRAINT COPY
DO
EXPLAIN EXTEND
LISTEN LOAD LOCK
MOVE
NEW NONE NOTIFY
OFFSET
RESET
SETOF SHOW
UNLISTEN UNTIL
VACUUM VERBOSE
</programlisting>
</para> </para>
<para> <para>
The following are <productname>Postgres</productname> Identifier and key word names are case insensitive. Therefore
reserved words that are also <acronym>SQL92</acronym>
or <acronym>SQL3</acronym> reserved words, and that
are allowed to be present as column labels, but not as identifiers:
<programlisting> <programlisting>
ALL ANY ASC BETWEEN BIT BOTH UPDATE MY_TABLE SET A = 5;
CASE CAST CHAR CHARACTER CHECK COALESCE COLLATE COLUMN
CONSTRAINT CROSS CURRENT CURRENT_DATE CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_USER
DEC DECIMAL DEFAULT DESC DISTINCT
ELSE END EXCEPT EXISTS EXTRACT
FALSE FLOAT FOR FOREIGN FROM FULL
GLOBAL GROUP
HAVING
IN INNER INTERSECT INTO IS
JOIN
LEADING LEFT LIKE LOCAL
NATURAL NCHAR NOT NULL NULLIF NUMERIC
ON OR ORDER OUTER OVERLAPS
POSITION PRECISION PRIMARY PUBLIC
REFERENCES RIGHT
SELECT SESSION_USER SOME SUBSTRING
TABLE THEN TO TRANSACTION TRIM TRUE
UNION UNIQUE USER
VARCHAR
WHEN WHERE
</programlisting> </programlisting>
can equivalently be written as
The following are <productname>Postgres</productname>
reserved words that are also <acronym>SQL92</acronym>
or <acronym>SQL3</acronym> reserved words:
<programlisting> <programlisting>
ADD ALTER AND AS uPDaTE my_TabLE SeT a = 5;
BEGIN BY
CASCADE CLOSE COMMIT CREATE CURSOR
DECLARE DEFAULT DELETE DESC DISTINCT DROP
EXECUTE EXISTS EXTRACT
FETCH FLOAT FOR FROM FULL
GRANT
HAVING
IN INNER INSERT INTERVAL INTO INOUT IS
JOIN
LEADING LEFT LIKE LOCAL
NAMES NATIONAL NATURAL NCHAR NO NOT NULL
ON OR OUT OUTER
PARTIAL PRIMARY PRIVILEGES PROCEDURE PUBLIC
REFERENCES REVOKE RIGHT ROLLBACK
SELECT SESSION SET SUBSTRING
TO TRAILING TRIM
UNION UNIQUE UPDATE USING
VALUES VARCHAR VARYING VIEW
WHERE WITH WITHOUT WORK
</programlisting> </programlisting>
</para> A good convention to adopt is perhaps to write key words in upper
case and names in lower case, e.g.,
<para>
The following are <acronym>SQL92</acronym> reserved key words that
are not <productname>Postgres</productname> reserved key words, but that
if used as function names are always translated into the function
<function>CHAR_LENGTH</function>:
<programlisting> <programlisting>
CHARACTER_LENGTH UPDATE my_table SET a = 5;
</programlisting> </programlisting>
</para> </para>
<para> <para>
The following are <acronym>SQL92</acronym> or <acronym>SQL3</acronym> There is a second kind of identifier: the <firstterm>delimited
reserved key words that identifier</firstterm> or <firstterm>quoted
are not <productname>Postgres</productname> reserved key words, but identifier</firstterm>. It is formed by enclosing an arbitrary
if used as type names are always translated into an alternate, native type: 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> <programlisting>
BOOLEAN DOUBLE FLOAT INT INTEGER INTERVAL REAL SMALLINT UPDATE "my_table" SET "a" = 5;
</programlisting> </programlisting>
</para> </para>
<para> <para>
The following are not keywords of any kind, but when used in the Quoted identifiers can contain any character other than a double
context of a type name are translated into a native quote itself. This allows constructing table or column names that
<productname>Postgres</productname> type, and when used in the would otherwise not be possible, such as ones containing spaces or
context of a function name are translated into a native function: ampersands. The length limitation still applies.
<programlisting>
DATETIME TIMESPAN
</programlisting>
(translated to <type>TIMESTAMP</type> and <type>INTERVAL</type>,
respectively). This feature is intended to help with
transitioning to version 7.0, and will be removed in a future release.
</para> </para>
<para> <para>
The following are either <acronym>SQL92</acronym> Quoting an identifier also makes it case-sensitive, whereas
or <acronym>SQL3</acronym> reserved key words unquoted names are always folded to lower case. For example, the
that are not key words in <productname>Postgres</productname>. identifiers <literal>FOO</literal>, <literal>foo</literal> and
These have no proscribed usage in <productname>Postgres</productname> <literal>"foo"</literal> are considered the same by
at the time of writing (version 7.0) but may become reserved key words in the <productname>Postgres</productname>, but <literal>"Foo"</literal>
future: and <literal>"FOO"</literal> are different from these three and
each other.
<note> <footnote>
<para> <para>
Some of these key words represent functions in <acronym>SQL92</acronym>. This is incompatible with SQL, where unquoted names are folded to
These functions are defined in <productname>Postgres</productname>, upper case. Thus, <literal>foo</literal> is equivalent to
but the parser does not consider the names to be key words and they are allowed <literal>"FOO"</literal>. If you want to write portable
in other contexts. applications you are advised to always quote a particular name or
never quote it.
</para> </para>
</note> </footnote>
<programlisting>
ALLOCATE ARE ASSERTION AT AUTHORIZATION AVG
BIT_LENGTH
CASCADED CATALOG CHAR_LENGTH CHARACTER_LENGTH COLLATION
CONNECT CONNECTION CONTINUE CONVERT CORRESPONDING COUNT
CURRENT_SESSION
DATE DEALLOCATE DEC DESCRIBE DESCRIPTOR
DIAGNOSTICS DISCONNECT DOMAIN
ESCAPE EXCEPT EXCEPTION EXEC EXTERNAL
FIRST FOUND
GET GO GOTO
IDENTITY INDICATOR INPUT INTERSECT
LAST LOWER
MAX MIN MODULE
OCTET_LENGTH OPEN OUTPUT OVERLAPS
PREPARE PRESERVE
ROWS
SCHEMA SECTION SESSION SIZE SOME
SQL SQLCODE SQLERROR SQLSTATE SUM SYSTEM_USER
TEMPORARY TRANSLATE TRANSLATION
UNKNOWN UPPER USAGE
VALUE
WHENEVER WRITE
</programlisting>
</para> </para>
</sect2> </sect2>
<sect2>
<title>Non-reserved Keywords</title> <sect2 id="sql-syntax-constants">
<title>Constants</title>
<para> <para>
<acronym>SQL92</acronym> and <acronym>SQL3</acronym> have There are four kinds of <firstterm>implicitly typed
<firstterm>non-reserved keywords</firstterm> which have constants</firstterm> in <productname>Postgres</productname>:
a prescribed meaning in the language but which are also allowed strings, bit strings, integers, and floating point numbers.
as identifiers. Constants can also be specified with explicit types, which can
<productname>Postgres</productname> has additional keywords enable more accurate representation and more efficient handling by
which allow similar unrestricted usage. the system. The implicit constants are described below; explicit
In particular, these keywords constants are discussed afterwards.
are allowed as column or table names.
</para> </para>
<para> <sect3>
The following are <productname>Postgres</productname> <title>String Constants</title>
non-reserved key words that are neither <acronym>SQL92</acronym>
nor <acronym>SQL3</acronym> non-reserved key words:
<programlisting> <para>
ACCESS AFTER AGGREGATE A string constant in SQL is an arbitrary sequence of characters
BACKWARD BEFORE bounded by single quotes (<quote>'</quote>), e.g., <literal>'This
CACHE COMMENT CREATEDB CREATEUSER CYCLE is a string'</literal>. SQL allows single quotes to be embedded
DATABASE DELIMITERS in strings by typing two adjacent single quotes (e.g.,
EACH ENCODING EXCLUSIVE <literal>'Dianne''s horse'</literal>). In
FORCE FORWARD FUNCTION <productname>Postgres</productname> single quotes may
HANDLER alternatively be escaped with a backslash (<quote>\</quote>,
INCREMENT INDEX INHERITS INSENSITIVE INSTEAD ISNULL e.g., <literal>'Dianne\'s horse'</literal>).
LANCOMPILER LOCATION
MAXVALUE MINVALUE MODE
NOCREATEDB NOCREATEUSER NOTHING NOTIFY NOTNULL
OIDS OPERATOR
PASSWORD PROCEDURAL
RECIPE REINDEX RENAME RETURNS ROW RULE
SEQUENCE SERIAL SHARE START STATEMENT STDIN STDOUT
TEMP TRUSTED
UNLISTEN UNTIL
VALID VERSION
</programlisting>
</para> </para>
<para> <para>
The following are <productname>Postgres</productname> C-style backslash escapes are also available:
non-reserved key words that are <acronym>SQL92</acronym> <literal>\b</literal> is a backspace, <literal>\f</literal> is a
or <acronym>SQL3</acronym> reserved key words: form feed, <literal>\n</literal> is a newline,
<literal>\r</literal> is a carriage return, <literal>\t</literal>
<programlisting> is a tab, and <literal>\<replaceable>xxx</replaceable></literal>,
ABSOLUTE ACTION where <replaceable>xxx</replaceable> is an octal number, is the
CHARACTERISTICS CONSTRAINTS character with the corresponding ASCII code. Any other character
DAY DEFERRABLE DEFERRED following a backslash is taken literally. Thus, to include a
HOUR backslash in a string constant, type two backslashes.
IMMEDIATE INITIALLY INSENSITIVE ISOLATION
KEY
LANGUAGE LEVEL
MATCH MINUTE MONTH
NEXT
OF ONLY OPTION
PATH PENDANT PRIOR PRIVILEGES
READ RELATIVE RESTRICT
SCHEMA SCROLL SECOND
TIME TIMESTAMP TIMEZONE_HOUR TIMEZONE_MINUTE TRIGGER
YEAR
ZONE
</programlisting>
</para> </para>
<para> <para>
The following are <productname>Postgres</productname> The character with the code zero cannot be in a string constant.
non-reserved key words that are also either <acronym>SQL92</acronym> </para>
or <acronym>SQL3</acronym> non-reserved key words:
<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> <programlisting>
COMMITTED SERIALIZABLE TYPE SELECT 'foo' 'bar';
</programlisting> </programlisting>
is not valid syntax.
</para> </para>
</sect3>
<sect3>
<title>Bit String Constants</title>
<para> <para>
The following are either <acronym>SQL92</acronym> Bit string constants look like string constants with a
or <acronym>SQL3</acronym> non-reserved key words that are not <literal>B</literal> (upper or lower case) immediately before the
key words of any kind in <productname>Postgres</productname>: 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.
</para>
</sect3>
<programlisting> <sect3>
ADA <title>Integer Constants</title>
C CATALOG_NAME CHARACTER_SET_CATALOG CHARACTER_SET_NAME
CHARACTER_SET_SCHEMA CLASS_ORIGIN COBOL COLLATION_CATALOG <para>
COLLATION_NAME COLLATION_SCHEMA COLUMN_NAME Integer constants in SQL are sequences of decimal digits (0
COMMAND_FUNCTION CONDITION_NUMBER though 9) with no decimal point. The range of legal values
CONNECTION_NAME CONSTRAINT_CATALOG CONSTRAINT_NAME depends on which integer data type is used, but the plain
CONSTRAINT_SCHEMA CURSOR_NAME <type>integer</type> type accepts values ranging from -2147483648
DATA DATE_TIME_INTERVAL_CODE DATE_TIME_INTERVAL_PRECISION to +2147483647. (The optional plus or minus sign is actually a
DYNAMIC_FUNCTION separate unary operator and not part of the integer constant.)
FORTRAN
LENGTH
MESSAGE_LENGTH MESSAGE_OCTET_LENGTH MORE MUMPS
NAME NULLABLE NUMBER
PAD PASCAL PLI
REPEATABLE RETURNED_LENGTH RETURNED_OCTET_LENGTH
RETURNED_SQLSTATE ROW_COUNT
SCALE SCHEMA_NAME SERVER_NAME SPACE SUBCLASS_ORIGIN
TABLE_NAME
UNCOMMITTED UNNAMED
</programlisting>
</para> </para>
</sect2> </sect3>
</sect1>
<sect1 id="sql-comments"> <sect3>
<title>Comments</title> <title>Floating Point Constants</title>
<para> <para>
A <firstterm>comment</firstterm> Floating point constants are accepted in these general forms:
is an arbitrary sequence of characters beginning with double dashes <synopsis>
and extending to the end of the line, e.g.: <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.
</para>
<programlisting> <informalexample>
-- This is a standard SQL comment <para>
</programlisting> These are some examples of valid floating point constants:
<literallayout>
3.5
4.
.001
5e2
1.925e-3
</literallayout>
</para> </para>
</informalexample>
<para> <para>
We also support C-style block comments, e.g.: 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
<productname>Postgres</productname> type notation:
<programlisting> <programlisting>
/* multi-line comment REAL '1.23' -- string style
* with nesting: /* nested block comment */ '1.23'::REAL -- Postgres (historical) style
*/
</programlisting> </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, so that one can comment out
larger blocks of code that may contain existing block comments.
</para> </para>
</sect1> </sect3>
<sect1 id="sql-names"> <sect3>
<title>Names</title> <title>Constants of Other Types</title>
<para> <para>
Names in SQL must begin with a letter A constant of an <emphasis>arbitrary</emphasis> type can be
(<literal>a</literal>-<literal>z</literal>) or underscore entered using any one of the following notations:
(<literal>_</literal>). <synopsis>
Subsequent characters in a name can be letters, digits <replaceable>type</replaceable> '<replaceable>string</replaceable>'
(<literal>0</literal>-<literal>9</literal>), '<replaceable>string</replaceable>'::<replaceable>type</replaceable>
or underscores. The system uses no more than NAMEDATALEN-1 characters CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
of a name; longer names can be written in queries, but they will be </synopsis>
truncated. The value inside the string is passed to the input conversion
By default, NAMEDATALEN is 32 so the maximum name length is 31 (but routine for the type called <replaceable>type</replaceable>. The
at the time the system is built, NAMEDATALEN can be changed in result is a constant of the indicated type. The explicit type
<filename>src/include/postgres_ext.h</filename>). 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.
</para> </para>
<para> <para>
Names containing other characters may be formed by surrounding them It is also possible to specify a type coercion using a function-like
with double quotes (<literal>"</literal>). For example, table or column syntax:
names may contain <synopsis>
otherwise disallowed characters such as spaces, ampersands, etc. if <replaceable>typename</replaceable> ( <replaceable>value</replaceable> )
quoted. Quoting a name also makes it case-sensitive, </synopsis>
whereas unquoted names are always folded to lower case. For example, although this only works for types whose names are also valid as
the names <literal>FOO</literal>, <literal>foo</literal> function names. (For example, <literal>double precision</literal>
and <literal>"foo"</literal> are can't be used this way --- but the equivalent <literal>float8</literal>
considered the same by <productname>Postgres</productname>, but can.)
<literal>"Foo"</literal> is a different name.
</para> </para>
<para> <para>
Double quotes can also be used to protect a name that would otherwise The <literal>::</literal>, <literal>CAST()</literal>, and
be taken to be an SQL keyword. For example, <literal>IN</literal> function-call syntaxes can also be used to specify the type of
is a keyword but <literal>"IN"</literal> is a name. arbitrary expressions, but the form
<replaceable>type</replaceable>
'<replaceable>string</replaceable>' can only be used to specify
the type of a literal constant.
</para> </para>
</sect1> </sect3>
<sect1 id="sql-constants"> <sect3>
<title>Constants</title> <title>Array constants</title>
<para> <para>
There are three kinds of <firstterm>implicitly typed constants</firstterm> The general format of an array constant is the following:
in <productname>Postgres</productname>: strings, integers, <synopsis>
and floating point numbers. Constants can '{ <replaceable>val1</replaceable> <replaceable>delim</replaceable> <replaceable>val2</replaceable> <replaceable>delim</replaceable> ... }'
also be specified with explicit types, which can enable more </synopsis>
accurate representation and more efficient handling by the where <replaceable>delim</replaceable> is the delimiter character
backend. The implicit constants are described below; explicit for the type, as recorded in its <literal>pg_type</literal>
constants are discussed afterwards. 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>
This constant is a two-dimensional, 3 by 3 array consisting of three
sub-arrays of integers.
</para> </para>
<sect2>
<title>String Constants</title>
<para> <para>
<firstterm>Strings</firstterm> Individual array elements can be placed between double-quote
in SQL are arbitrary sequences of ASCII characters bounded by single marks (<literal>"</literal>) <!-- " --> to avoid ambiguity
quotes ("'", e.g. <literal>'This is a string'</literal>). problems with respect to white space. Without quote marks, the
SQL92 allows single quotes to be embedded in strings by typing two array-value parser will skip leading white space.
adjacent single quotes (e.g. <literal>'Dianne''s horse'</literal>).
In <productname>Postgres</productname> single quotes may alternatively
be escaped with a backslash ("\", e.g.
<literal>'Dianne\'s horse'</literal>). To include a
backslash in a string constant, type two backslashes.
Non-printing characters may also be embedded within strings by
prepending them with a backslash
(e.g. <literal>'\<replaceable>tab</replaceable>'</literal>).
</para> </para>
</sect2>
<sect2>
<title>Integer Constants</title>
<para> <para>
<firstterm>Integer constants</firstterm> (Array constants are actually only a special case of the generic
in SQL are sequences of ASCII digits with no decimal point. type constants discussed in the previous section. The constant
The range of legal values depends on which integer datatype is is initially treated as a string and passed to the array input
used, but the plain <literal>integer</literal> type accepts values conversion routine. An explicit type specification might be
ranging from -2147483648 to +2147483647. necessary.)
</para> </para>
</sect3>
</sect2> </sect2>
<sect2>
<title>Floating Point Constants</title>
<para> <sect2 id="sql-syntax-operators">
<firstterm>Floating point constants</firstterm> <title>Operators</title>
consist of an integer part, a decimal point, and a fraction part or
scientific notation of the following format:
<synopsis> <para>
{<replaceable>dig</replaceable>}.{<replaceable>dig</replaceable>} [e [+-] {<replaceable>dig</replaceable>}] An operator is a sequence of up to <symbol>NAMEDATALEN</symbol>-1
</synopsis> (31 by default) characters from the following list:
<literallayout>
+ - * / &lt; &gt; = ~ ! @ # % ^ &amp; | ` ? $
</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>
where <replaceable>dig</replaceable> is one or more digits. <listitem>
You must include at least one <replaceable>dig</replaceable> after the <para>
period and after the [+-] if you use those options. An exponent with <literal>--</literal> and <literal>/*</literal> cannot appear
a missing mantissa has a mantissa of 1 inserted. There may be no anywhere in an operator name, since they will be taken as the
extra characters embedded in the string. start of a comment.
</para> </para>
</listitem>
<listitem>
<para> <para>
Floating point constaints are of type A multi-character operator name cannot end in "+" or "-",
<type>float8</type>. <type>float4</type> can be specified unless the name also contains at least one of these characters:
explicitly by using <acronym>SQL92</acronym> string notation or <literallayout>
<productname>Postgres</productname> type notation: ~ ! @ # % ^ &amp; | ` ? $
</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>
<programlisting> <para>
float4 '1.23' -- string style When working with non-SQL-standard operator names, you will usually
'1.23'::float4 -- Postgres (historical) style need to separate adjacent operators with spaces to avoid ambiguity.
</programlisting> 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> </para>
</sect2> </sect2>
<sect2> <sect2>
<title>Constants of Postgres User-Defined Types</title> <title>Special Characters</title>
<para> <para>
A constant of an Some characters that are not alphanumeric have a special meaning
<emphasis>arbitrary</emphasis> that is different from being an operator. Details on the usage can
type can be entered using any one of the following notations: 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.
<synopsis> <itemizedlist>
<replaceable>type</replaceable> '<replaceable>string</replaceable>' <listitem>
'<replaceable>string</replaceable>'::<replaceable>type</replaceable> <para>
CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) A dollar sign (<literal>$</literal>) followed by digits is used
</synopsis> 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>
The value inside the string is passed to the input <listitem>
conversion routine for the type called <para>
<replaceable>type</replaceable>. The result is a Parentheses (<literal>()</literal>) have their usual meaning to
constant of the indicated type. The explicit typecast may be omitted group expressions and enforce precedence. In some cases
if there is no ambiguity as to the type the constant must be, in which parentheses are required as part of the fixed syntax of a
case it is automatically coerced. particular SQL command.
</para> </para>
</listitem>
<listitem>
<para> <para>
It is also possible to specify a type coercion using a function-like Brackets (<literal>[]</literal>) are used to select the elements
syntax: of an array. See <xref linkend="arrays"> for more information
on arrays.
</para>
</listitem>
<synopsis> <listitem>
<replaceable>typename</replaceable> ( <replaceable>value</replaceable> ) <para>
</synopsis> Commas (<literal>,</literal>) are used in some syntactical
constructs to separate the elements of a list.
</para>
</listitem>
although this only works for types whose names are also valid as <listitem>
function names. (For example, <literal>double precision</literal> <para>
can't be used this way --- but the equivalent <literal>float8</literal> The semicolon (<literal>;</literal>) terminates an SQL command.
can.) It cannot appear anywhere within a command, except when quoted
as a string constant or identifier.
</para> </para>
</listitem>
<listitem>
<para> <para>
The <literal>::</literal>, <literal>CAST()</literal>, and function-call The colon (<literal>:</literal>) is used to select
syntaxes can also be used to specify run-time type conversions. But <quote>slices</quote> from arrays. (See <xref
the form <replaceable>type</replaceable> linkend="arrays">.) In certain SQL dialects (such as Embedded
'<replaceable>string</replaceable>' can only be used to specify the SQL), the colon is used to prefix variable names.
type of a literal constant.
</para> </para>
</sect2> </listitem>
<sect2> <listitem>
<title>Array constants</title> <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> <para>
<firstterm>Array constants</firstterm> The period (<literal>.</literal>) is used in floating point
are n-dimensional arrays of any Postgres datatype. constants, and to separate table and column names.
The general format of an array constant is the following: </para>
</listitem>
</itemizedlist>
<synopsis> </para>
{ <replaceable>val1</replaceable> <replaceable>delim</replaceable> <replaceable>val2</replaceable> <replaceable>delim</replaceable> ... } </sect2>
</synopsis>
where <replaceable>delim</replaceable> <sect2 id="sql-syntax-comments">
is the delimiter character for the type, as recorded in its <title>Comments</title>
<literal>pg_type</literal> class 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
<para>
A comment is an arbitrary sequence of characters beginning with
double dashes and extending to the end of the line, e.g.:
<programlisting> <programlisting>
{{1,2,3},{4,5,6},{7,8,9}} -- This is a standard SQL92 comment
</programlisting> </programlisting>
</para>
This constant is a two-dimensional, 3 by 3 array consisting of three <para>
sub-arrays of integers. 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>
<para> <para>
Individual array elements can be placed between double-quote A comment is removed from the input stream before further syntax
marks (<literal>"</literal>) to avoid ambiguity problems with respect to analysis and is effectively replaced by whitespace.
white space.
Without quote marks, the array-value parser will skip leading white space.
</para> </para>
</sect2> </sect2>
</sect1> </sect1>
<sect1 id="sql-columns">
<sect1 id="sql-syntax-columns">
<title>Fields and Columns</title> <title>Fields and Columns</title>
<sect2> <sect2>
@ -664,18 +654,6 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</sect2> </sect2>
</sect1> </sect1>
<sect1 id="sql-operators">
<title>Operators</title>
<para>
Any built-in or user-defined operator may be used in SQL.
For the list of built-in operators consult <xref linkend="functions">.
For a list of user-defined operators consult your system administrator
or run a query on the <literal>pg_operator</literal> class.
Parentheses may be used for arbitrary grouping of operators in expressions.
</para>
</sect1>
<sect1 id="sql-expressions"> <sect1 id="sql-expressions">
<title>Expressions</title> <title>Expressions</title>

@ -1,5 +1,5 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.22 2000/12/16 02:29:36 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.23 2001/01/06 11:58:56 petere Exp $
--> -->
<book id="user"> <book id="user">
@ -62,6 +62,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.22 2000/12/16 02:29:36
<!-- appendices --> <!-- appendices -->
&datetime; &datetime;
&keywords;
&biblio; &biblio;

Loading…
Cancel
Save