1 <!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.130 2009/02/04 21:30:41 alvherre Exp $ -->
3 <chapter id="sql-syntax">
4 <title>SQL Syntax</title>
6 <indexterm zone="sql-syntax">
7 <primary>syntax</primary>
8 <secondary>SQL</secondary>
12 This chapter describes the syntax of SQL. It forms the foundation
13 for understanding the following chapters which will go into detail
14 about how the SQL commands are applied to define and modify data.
18 We also advise users who are already familiar with SQL to read this
19 chapter carefully because there are several rules and concepts that
20 are implemented inconsistently among SQL databases or that are
21 specific to <productname>PostgreSQL</productname>.
24 <sect1 id="sql-syntax-lexical">
25 <title>Lexical Structure</title>
28 <primary>token</primary>
32 SQL input consists of a sequence of
33 <firstterm>commands</firstterm>. A command is composed of a
34 sequence of <firstterm>tokens</firstterm>, terminated by a
35 semicolon (<quote>;</quote>). The end of the input stream also
36 terminates a command. Which tokens are valid depends on the syntax
37 of the particular command.
41 A token can be a <firstterm>key word</firstterm>, an
42 <firstterm>identifier</firstterm>, a <firstterm>quoted
43 identifier</firstterm>, a <firstterm>literal</firstterm> (or
44 constant), or a special character symbol. Tokens are normally
45 separated by whitespace (space, tab, newline), but need not be if
46 there is no ambiguity (which is generally only the case if a
47 special character is adjacent to some other token type).
51 Additionally, <firstterm>comments</firstterm> can occur in SQL
52 input. They are not tokens, they are effectively equivalent to
57 For example, the following is (syntactically) valid SQL input:
59 SELECT * FROM MY_TABLE;
60 UPDATE MY_TABLE SET A = 5;
61 INSERT INTO MY_TABLE VALUES (3, 'hi there');
63 This is a sequence of three commands, one per line (although this
64 is not required; more than one command can be on a line, and
65 commands can usefully be split across lines).
69 The SQL syntax is not very consistent regarding what tokens
70 identify commands and which are operands or parameters. The first
71 few tokens are generally the command name, so in the above example
72 we would usually speak of a <quote>SELECT</quote>, an
73 <quote>UPDATE</quote>, and an <quote>INSERT</quote> command. But
74 for instance the <command>UPDATE</command> command always requires
75 a <token>SET</token> token to appear in a certain position, and
76 this particular variation of <command>INSERT</command> also
77 requires a <token>VALUES</token> in order to be complete. The
78 precise syntax rules for each command are described in <xref linkend="reference">.
81 <sect2 id="sql-syntax-identifiers">
82 <title>Identifiers and Key Words</title>
84 <indexterm zone="sql-syntax-identifiers">
85 <primary>identifier</primary>
86 <secondary>syntax of</secondary>
89 <indexterm zone="sql-syntax-identifiers">
90 <primary>name</primary>
91 <secondary>syntax of</secondary>
94 <indexterm zone="sql-syntax-identifiers">
95 <primary>key word</primary>
96 <secondary>syntax of</secondary>
100 Tokens such as <token>SELECT</token>, <token>UPDATE</token>, or
101 <token>VALUES</token> in the example above are examples of
102 <firstterm>key words</firstterm>, that is, words that have a fixed
103 meaning in the SQL language. The tokens <token>MY_TABLE</token>
104 and <token>A</token> are examples of
105 <firstterm>identifiers</firstterm>. They identify names of
106 tables, columns, or other database objects, depending on the
107 command they are used in. Therefore they are sometimes simply
108 called <quote>names</quote>. Key words and identifiers have the
109 same lexical structure, meaning that one cannot know whether a
110 token is an identifier or a key word without knowing the language.
111 A complete list of key words can be found in <xref
112 linkend="sql-keywords-appendix">.
116 SQL identifiers and key words must begin with a letter
117 (<literal>a</literal>-<literal>z</literal>, but also letters with
118 diacritical marks and non-Latin letters) or an underscore
119 (<literal>_</literal>). Subsequent characters in an identifier or
120 key word can be letters, underscores, digits
121 (<literal>0</literal>-<literal>9</literal>), or dollar signs
122 (<literal>$</>). Note that dollar signs are not allowed in identifiers
123 according to the letter of the SQL standard, so their use might render
124 applications less portable.
125 The SQL standard will not define a key word that contains
126 digits or starts or ends with an underscore, so identifiers of this
127 form are safe against possible conflict with future extensions of the
132 <indexterm><primary>identifier</primary><secondary>length</secondary></indexterm>
133 The system uses no more than <symbol>NAMEDATALEN</symbol>-1
134 bytes of an identifier; longer names can be written in
135 commands, but they will be truncated. By default,
136 <symbol>NAMEDATALEN</symbol> is 64 so the maximum identifier
137 length is 63 bytes. If this limit is problematic, it can be raised by
138 changing the <symbol>NAMEDATALEN</symbol> constant in
139 <filename>src/include/pg_config_manual.h</filename>.
144 <primary>case sensitivity</primary>
145 <secondary>of SQL commands</secondary>
147 Identifier and key word names are case insensitive. Therefore:
149 UPDATE MY_TABLE SET A = 5;
151 can equivalently be written as:
153 uPDaTE my_TabLE SeT a = 5;
155 A convention often used is to write key words in upper
156 case and names in lower case, e.g.:
158 UPDATE my_table SET a = 5;
164 <primary>quotation marks</primary>
165 <secondary>and identifiers</secondary>
167 There is a second kind of identifier: the <firstterm>delimited
168 identifier</firstterm> or <firstterm>quoted
169 identifier</firstterm>. It is formed by enclosing an arbitrary
170 sequence of characters in double-quotes
171 (<literal>"</literal>). <!-- " font-lock mania --> A delimited
172 identifier is always an identifier, never a key word. So
173 <literal>"select"</literal> could be used to refer to a column or
174 table named <quote>select</quote>, whereas an unquoted
175 <literal>select</literal> would be taken as a key word and
176 would therefore provoke a parse error when used where a table or
177 column name is expected. The example can be written with quoted
178 identifiers like this:
180 UPDATE "my_table" SET "a" = 5;
185 Quoted identifiers can contain any character, except the character
186 with code zero. (To include a double quote, write two double quotes.)
187 This allows constructing table or column names that would
188 otherwise not be possible, such as ones containing spaces or
189 ampersands. The length limitation still applies.
193 <indexterm><primary>Unicode escape</primary><secondary>in
194 identifiers</secondary></indexterm> A variant of quoted
195 identifiers allows including escaped Unicode characters identified
196 by their code points. This variant starts
197 with <literal>U&</literal> (upper or lower case U followed by
198 ampersand) immediately before the opening double quote, without
199 any spaces in between, for example <literal>U&"foo"</literal>.
200 (Note that this creates an ambiguity with the
201 operator <literal>&</literal>. Use spaces around the operator to
202 avoid this problem.) Inside the quotes, Unicode characters can be
203 specified in escaped form by writing a backslash followed by the
204 four-digit hexadecimal code point number or alternatively a
205 backslash followed by a plus sign followed by a six-digit
206 hexadecimal code point number. For example, the
207 identifier <literal>"data"</literal> could be written as
209 U&"d\0061t\+000061"
211 The following less trivial example writes the Russian
212 word <quote>slon</quote> (elephant) in Cyrillic letters:
214 U&"\0441\043B\043E\043D"
219 If a different escape character than backslash is desired, it can
221 the <literal>UESCAPE</literal><indexterm><primary>UESCAPE</primary></indexterm>
222 clause after the string, for example:
224 U&"d!0061t!+000061" UESCAPE '!'
226 The escape character can be any single character other than a
227 hexadecimal digit, the plus sign, a single quote, a double quote,
228 or a whitespace character. Note that the escape character is
229 written in single quotes, not double quotes.
233 To include the escape character in the identifier literally, write
238 The Unicode escape syntax works only when the server encoding is
239 UTF8. When other server encodings are used, only code points in
240 the ASCII range (up to <literal>\007F</literal>) can be specified.
244 Quoting an identifier also makes it case-sensitive, whereas
245 unquoted names are always folded to lower case. For example, the
246 identifiers <literal>FOO</literal>, <literal>foo</literal>, and
247 <literal>"foo"</literal> are considered the same by
248 <productname>PostgreSQL</productname>, but
249 <literal>"Foo"</literal> and <literal>"FOO"</literal> are
250 different from these three and each other. (The folding of
251 unquoted names to lower case in <productname>PostgreSQL</> is
252 incompatible with the SQL standard, which says that unquoted names
253 should be folded to upper case. Thus, <literal>foo</literal>
254 should be equivalent to <literal>"FOO"</literal> not
255 <literal>"foo"</literal> according to the standard. If you want
256 to write portable applications you are advised to always quote a
257 particular name or never quote it.)
262 <sect2 id="sql-syntax-constants">
263 <title>Constants</title>
265 <indexterm zone="sql-syntax-constants">
266 <primary>constant</primary>
270 There are three kinds of <firstterm>implicitly-typed
271 constants</firstterm> in <productname>PostgreSQL</productname>:
272 strings, bit strings, and numbers.
273 Constants can also be specified with explicit types, which can
274 enable more accurate representation and more efficient handling by
275 the system. These alternatives are discussed in the following
279 <sect3 id="sql-syntax-strings">
280 <title>String Constants</title>
282 <indexterm zone="sql-syntax-strings">
283 <primary>character string</primary>
284 <secondary>constant</secondary>
289 <primary>quotation marks</primary>
290 <secondary>escaping</secondary>
292 A string constant in SQL is an arbitrary sequence of characters
293 bounded by single quotes (<literal>'</literal>), for example
294 <literal>'This is a string'</literal>. To include
295 a single-quote character within a string constant,
296 write two adjacent single quotes, e.g.
297 <literal>'Dianne''s horse'</literal>.
298 Note that this is <emphasis>not</> the same as a double-quote
299 character (<literal>"</>). <!-- font-lock sanity: " -->
303 Two string constants that are only separated by whitespace
304 <emphasis>with at least one newline</emphasis> are concatenated
305 and effectively treated as if the string had been written as one
306 constant. For example:
319 is not valid syntax. (This slightly bizarre behavior is specified
320 by <acronym>SQL</acronym>; <productname>PostgreSQL</productname> is
321 following the standard.)
325 <sect3 id="sql-syntax-strings-escape">
326 <title>String Constants with C-Style Escapes</title>
328 <indexterm zone="sql-syntax-strings-escape">
329 <primary>escape string syntax</primary>
331 <indexterm zone="sql-syntax-strings-escape">
332 <primary>backslash escapes</primary>
336 <productname>PostgreSQL</productname> also accepts <quote>escape</>
337 string constants, which are an extension to the SQL standard.
338 An escape string constant is specified by writing the letter
339 <literal>E</literal> (upper or lower case) just before the opening single
340 quote, e.g. <literal>E'foo'</>. (When continuing an escape string
341 constant across lines, write <literal>E</> only before the first opening
343 Within an escape string, a backslash character (<literal>\</>) begins a
344 C-like <firstterm>backslash escape</> sequence, in which the combination
345 of backslash and following character(s) represent a special byte
346 value, as shown in <xref linkend="sql-backslash-table">.
349 <table id="sql-backslash-table">
350 <title>Backslash Escape Sequences</title>
354 <entry>Backslash Escape Sequence</>
355 <entry>Interpretation</entry>
361 <entry><literal>\b</literal></entry>
362 <entry>backspace</entry>
365 <entry><literal>\f</literal></entry>
366 <entry>form feed</entry>
369 <entry><literal>\n</literal></entry>
370 <entry>newline</entry>
373 <entry><literal>\r</literal></entry>
374 <entry>carriage return</entry>
377 <entry><literal>\t</literal></entry>
382 <literal>\<replaceable>o</replaceable></literal>,
383 <literal>\<replaceable>oo</replaceable></literal>,
384 <literal>\<replaceable>ooo</replaceable></literal>
385 (<replaceable>o</replaceable> = 0 - 7)
387 <entry>octal byte value</entry>
391 <literal>\x<replaceable>h</replaceable></literal>,
392 <literal>\x<replaceable>hh</replaceable></literal>
393 (<replaceable>h</replaceable> = 0 - 9, A - F)
395 <entry>hexadecimal byte value</entry>
403 character following a backslash is taken literally. Thus, to
404 include a backslash character, write two backslashes (<literal>\\</>).
405 Also, a single quote can be included in an escape string by writing
406 <literal>\'</literal>, in addition to the normal way of <literal>''</>.
410 It is your responsibility that the byte sequences you create are
411 valid characters in the server character set encoding. When the
412 server encoding is UTF-8, then the alternative Unicode escape
413 syntax, explained in <xref linkend="sql-syntax-strings-uescape">,
414 should be used instead. (The alternative would be doing the
415 UTF-8 encoding by hand and writing out the bytes, which would be
421 If the configuration parameter
422 <xref linkend="guc-standard-conforming-strings"> is <literal>off</>,
423 then <productname>PostgreSQL</productname> recognizes backslash escapes
424 in both regular and escape string constants. This is for backward
425 compatibility with the historical behavior, in which backslash escapes
426 were always recognized.
427 Although <varname>standard_conforming_strings</> currently defaults to
428 <literal>off</>, the default will change to <literal>on</> in a future
429 release for improved standards compliance. Applications are therefore
430 encouraged to migrate away from using backslash escapes. If you need
431 to use a backslash escape to represent a special character, write the
432 constant with an <literal>E</> to be sure it will be handled the same
433 way in future releases.
437 In addition to <varname>standard_conforming_strings</>, the configuration
438 parameters <xref linkend="guc-escape-string-warning"> and
439 <xref linkend="guc-backslash-quote"> govern treatment of backslashes
445 The character with the code zero cannot be in a string constant.
449 <sect3 id="sql-syntax-strings-uescape">
450 <title>String Constants with Unicode Escapes</title>
452 <indexterm zone="sql-syntax-strings-uescape">
453 <primary>Unicode escape</primary>
454 <secondary>in string constants</secondary>
458 <productname>PostgreSQL</productname> also supports another type
459 of escape syntax for strings that allows specifying arbitrary
460 Unicode characters by code point. A Unicode escape string
461 constant starts with <literal>U&</literal> (upper or lower case
462 letter U followed by ampersand) immediately before the opening
463 quote, without any spaces in between, for
464 example <literal>U&'foo'</literal>. (Note that this creates an
465 ambiguity with the operator <literal>&</literal>. Use spaces
466 around the operator to avoid this problem.) Inside the quotes,
467 Unicode characters can be specified in escaped form by writing a
468 backslash followed by the four-digit hexadecimal code point
469 number or alternatively a backslash followed by a plus sign
470 followed by a six-digit hexadecimal code point number. For
471 example, the string <literal>'data'</literal> could be written as
473 U&'d\0061t\+000061'
475 The following less trivial example writes the Russian
476 word <quote>slon</quote> (elephant) in Cyrillic letters:
478 U&'\0441\043B\043E\043D'
483 If a different escape character than backslash is desired, it can
485 the <literal>UESCAPE</literal><indexterm><primary>UESCAPE</primary></indexterm>
486 clause after the string, for example:
488 U&'d!0061t!+000061' UESCAPE '!'
490 The escape character can be any single character other than a
491 hexadecimal digit, the plus sign, a single quote, a double quote,
492 or a whitespace character.
496 The Unicode escape syntax works only when the server encoding is
497 UTF8. When other server encodings are used, only code points in
498 the ASCII range (up to <literal>\007F</literal>) can be
503 To include the escape character in the string literally, write it
508 <sect3 id="sql-syntax-dollar-quoting">
509 <title>Dollar-Quoted String Constants</title>
512 <primary>dollar quoting</primary>
516 While the standard syntax for specifying string constants is usually
517 convenient, it can be difficult to understand when the desired string
518 contains many single quotes or backslashes, since each of those must
519 be doubled. To allow more readable queries in such situations,
520 <productname>PostgreSQL</productname> provides another way, called
521 <quote>dollar quoting</quote>, to write string constants.
522 A dollar-quoted string constant
523 consists of a dollar sign (<literal>$</literal>), an optional
524 <quote>tag</quote> of zero or more characters, another dollar
525 sign, an arbitrary sequence of characters that makes up the
526 string content, a dollar sign, the same tag that began this
527 dollar quote, and a dollar sign. For example, here are two
528 different ways to specify the string <quote>Dianne's horse</>
529 using dollar quoting:
532 $SomeTag$Dianne's horse$SomeTag$
534 Notice that inside the dollar-quoted string, single quotes can be
535 used without needing to be escaped. Indeed, no characters inside
536 a dollar-quoted string are ever escaped: the string content is always
537 written literally. Backslashes are not special, and neither are
538 dollar signs, unless they are part of a sequence matching the opening
543 It is possible to nest dollar-quoted string constants by choosing
544 different tags at each nesting level. This is most commonly used in
545 writing function definitions. For example:
549 RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
553 Here, the sequence <literal>$q$[\t\r\n\v\\]$q$</> represents a
554 dollar-quoted literal string <literal>[\t\r\n\v\\]</>, which will
555 be recognized when the function body is executed by
556 <productname>PostgreSQL</>. But since the sequence does not match
557 the outer dollar quoting delimiter <literal>$function$</>, it is
558 just some more characters within the constant so far as the outer
563 The tag, if any, of a dollar-quoted string follows the same rules
564 as an unquoted identifier, except that it cannot contain a dollar sign.
565 Tags are case sensitive, so <literal>$tag$String content$tag$</literal>
566 is correct, but <literal>$TAG$String content$tag$</literal> is not.
570 A dollar-quoted string that follows a keyword or identifier must
571 be separated from it by whitespace; otherwise the dollar quoting
572 delimiter would be taken as part of the preceding identifier.
576 Dollar quoting is not part of the SQL standard, but it is often a more
577 convenient way to write complicated string literals than the
578 standard-compliant single quote syntax. It is particularly useful when
579 representing string constants inside other constants, as is often needed
580 in procedural function definitions. With single-quote syntax, each
581 backslash in the above example would have to be written as four
582 backslashes, which would be reduced to two backslashes in parsing the
583 original string constant, and then to one when the inner string constant
584 is re-parsed during function execution.
588 <sect3 id="sql-syntax-bit-strings">
589 <title>Bit-String Constants</title>
591 <indexterm zone="sql-syntax-bit-strings">
592 <primary>bit string</primary>
593 <secondary>constant</secondary>
597 Bit-string constants look like regular string constants with a
598 <literal>B</literal> (upper or lower case) immediately before the
599 opening quote (no intervening whitespace), e.g.,
600 <literal>B'1001'</literal>. The only characters allowed within
601 bit-string constants are <literal>0</literal> and
602 <literal>1</literal>.
606 Alternatively, bit-string constants can be specified in hexadecimal
607 notation, using a leading <literal>X</literal> (upper or lower case),
608 e.g., <literal>X'1FF'</literal>. This notation is equivalent to
609 a bit-string constant with four binary digits for each hexadecimal digit.
613 Both forms of bit-string constant can be continued
614 across lines in the same way as regular string constants.
615 Dollar quoting cannot be used in a bit-string constant.
620 <title>Numeric Constants</title>
623 <primary>number</primary>
624 <secondary>constant</secondary>
628 Numeric constants are accepted in these general forms:
630 <replaceable>digits</replaceable>
631 <replaceable>digits</replaceable>.<optional><replaceable>digits</replaceable></optional><optional>e<optional>+-</optional><replaceable>digits</replaceable></optional>
632 <optional><replaceable>digits</replaceable></optional>.<replaceable>digits</replaceable><optional>e<optional>+-</optional><replaceable>digits</replaceable></optional>
633 <replaceable>digits</replaceable>e<optional>+-</optional><replaceable>digits</replaceable>
635 where <replaceable>digits</replaceable> is one or more decimal
636 digits (0 through 9). At least one digit must be before or after the
637 decimal point, if one is used. At least one digit must follow the
638 exponent marker (<literal>e</literal>), if one is present.
639 There cannot be any spaces or other characters embedded in the
640 constant. Note that any leading plus or minus sign is not actually
641 considered part of the constant; it is an operator applied to the
646 These are some examples of valid numeric constants:
658 <indexterm><primary>integer</primary></indexterm>
659 <indexterm><primary>bigint</primary></indexterm>
660 <indexterm><primary>numeric</primary></indexterm>
661 A numeric constant that contains neither a decimal point nor an
662 exponent is initially presumed to be type <type>integer</> if its
663 value fits in type <type>integer</> (32 bits); otherwise it is
664 presumed to be type <type>bigint</> if its
665 value fits in type <type>bigint</> (64 bits); otherwise it is
666 taken to be type <type>numeric</>. Constants that contain decimal
667 points and/or exponents are always initially presumed to be type
672 The initially assigned data type of a numeric constant is just a
673 starting point for the type resolution algorithms. In most cases
674 the constant will be automatically coerced to the most
675 appropriate type depending on context. When necessary, you can
676 force a numeric value to be interpreted as a specific data type
677 by casting it.<indexterm><primary>type cast</primary></indexterm>
678 For example, you can force a numeric value to be treated as type
679 <type>real</> (<type>float4</>) by writing:
682 REAL '1.23' -- string style
683 1.23::REAL -- PostgreSQL (historical) style
686 These are actually just special cases of the general casting
687 notations discussed next.
691 <sect3 id="sql-syntax-constants-generic">
692 <title>Constants of Other Types</title>
695 <primary>data type</primary>
696 <secondary>constant</secondary>
700 A constant of an <emphasis>arbitrary</emphasis> type can be
701 entered using any one of the following notations:
703 <replaceable>type</replaceable> '<replaceable>string</replaceable>'
704 '<replaceable>string</replaceable>'::<replaceable>type</replaceable>
705 CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
707 The string constant's text is passed to the input conversion
708 routine for the type called <replaceable>type</replaceable>. The
709 result is a constant of the indicated type. The explicit type
710 cast can be omitted if there is no ambiguity as to the type the
711 constant must be (for example, when it is assigned directly to a
712 table column), in which case it is automatically coerced.
716 The string constant can be written using either regular SQL
717 notation or dollar-quoting.
721 It is also possible to specify a type coercion using a function-like
724 <replaceable>typename</replaceable> ( '<replaceable>string</replaceable>' )
726 but not all type names can be used in this way; see <xref
727 linkend="sql-syntax-type-casts"> for details.
731 The <literal>::</literal>, <literal>CAST()</literal>, and
732 function-call syntaxes can also be used to specify run-time type
733 conversions of arbitrary expressions, as discussed in <xref
734 linkend="sql-syntax-type-casts">. To avoid syntactic ambiguity, the
735 <literal><replaceable>type</> '<replaceable>string</>'</literal>
736 syntax can only be used to specify the type of a simple literal constant.
737 Another restriction on the
738 <literal><replaceable>type</> '<replaceable>string</>'</literal>
739 syntax is that it does not work for array types; use <literal>::</literal>
740 or <literal>CAST()</literal> to specify the type of an array constant.
744 The <literal>CAST()</> syntax conforms to SQL. The
745 <literal><replaceable>type</> '<replaceable>string</>'</literal>
746 syntax is a generalization of the standard: SQL specifies this syntax only
747 for a few data types, but <productname>PostgreSQL</productname> allows it
748 for all types. The syntax with
749 <literal>::</literal> is historical <productname>PostgreSQL</productname>
750 usage, as is the function-call syntax.
755 <sect2 id="sql-syntax-operators">
756 <title>Operators</title>
758 <indexterm zone="sql-syntax-operators">
759 <primary>operator</primary>
760 <secondary>syntax</secondary>
764 An operator name is a sequence of up to <symbol>NAMEDATALEN</symbol>-1
765 (63 by default) characters from the following list:
767 + - * / < > = ~ ! @ # % ^ & | ` ?
770 There are a few restrictions on operator names, however:
774 <literal>--</literal> and <literal>/*</literal> cannot appear
775 anywhere in an operator name, since they will be taken as the
782 A multiple-character operator name cannot end in <literal>+</> or <literal>-</>,
783 unless the name also contains at least one of these characters:
785 ~ ! @ # % ^ & | ` ?
787 For example, <literal>@-</literal> is an allowed operator name,
788 but <literal>*-</literal> is not. This restriction allows
789 <productname>PostgreSQL</productname> to parse SQL-compliant
790 queries without requiring spaces between tokens.
797 When working with non-SQL-standard operator names, you will usually
798 need to separate adjacent operators with spaces to avoid ambiguity.
799 For example, if you have defined a left unary operator named <literal>@</literal>,
800 you cannot write <literal>X*@Y</literal>; you must write
801 <literal>X* @Y</literal> to ensure that
802 <productname>PostgreSQL</productname> reads it as two operator names
808 <title>Special Characters</title>
811 Some characters that are not alphanumeric have a special meaning
812 that is different from being an operator. Details on the usage can
813 be found at the location where the respective syntax element is
814 described. This section only exists to advise the existence and
815 summarize the purposes of these characters.
820 A dollar sign (<literal>$</literal>) followed by digits is used
821 to represent a positional parameter in the body of a function
822 definition or a prepared statement. In other contexts the
823 dollar sign can be part of an identifier or a dollar-quoted string
830 Parentheses (<literal>()</literal>) have their usual meaning to
831 group expressions and enforce precedence. In some cases
832 parentheses are required as part of the fixed syntax of a
833 particular SQL command.
839 Brackets (<literal>[]</literal>) are used to select the elements
840 of an array. See <xref linkend="arrays"> for more information
847 Commas (<literal>,</literal>) are used in some syntactical
848 constructs to separate the elements of a list.
854 The semicolon (<literal>;</literal>) terminates an SQL command.
855 It cannot appear anywhere within a command, except within a
856 string constant or quoted identifier.
862 The colon (<literal>:</literal>) is used to select
863 <quote>slices</quote> from arrays. (See <xref
864 linkend="arrays">.) In certain SQL dialects (such as Embedded
865 SQL), the colon is used to prefix variable names.
871 The asterisk (<literal>*</literal>) is used in some contexts to denote
872 all the fields of a table row or composite value. It also
873 has a special meaning when used as the argument of an
874 aggregate function, namely that the aggregate does not require
875 any explicit parameter.
881 The period (<literal>.</literal>) is used in numeric
882 constants, and to separate schema, table, and column names.
890 <sect2 id="sql-syntax-comments">
891 <title>Comments</title>
893 <indexterm zone="sql-syntax-comments">
894 <primary>comment</primary>
895 <secondary sortas="SQL">in SQL</secondary>
899 A comment is an arbitrary sequence of characters beginning with
900 double dashes and extending to the end of the line, e.g.:
902 -- This is a standard SQL comment
907 Alternatively, C-style block comments can be used:
910 * with nesting: /* nested block comment */
913 where the comment begins with <literal>/*</literal> and extends to
914 the matching occurrence of <literal>*/</literal>. These block
915 comments nest, as specified in the SQL standard but unlike C, so that one can
916 comment out larger blocks of code that might contain existing block
921 A comment is removed from the input stream before further syntax
922 analysis and is effectively replaced by whitespace.
926 <sect2 id="sql-precedence">
927 <title>Lexical Precedence</title>
929 <indexterm zone="sql-precedence">
930 <primary>operator</primary>
931 <secondary>precedence</secondary>
935 <xref linkend="sql-precedence-table"> shows the precedence and
936 associativity of the operators in <productname>PostgreSQL</>.
937 Most operators have the same precedence and are left-associative.
938 The precedence and associativity of the operators is hard-wired
939 into the parser. This can lead to non-intuitive behavior; for
940 example the Boolean operators <literal><</> and
941 <literal>></> have a different precedence than the Boolean
942 operators <literal><=</> and <literal>>=</>. Also, you will
943 sometimes need to add parentheses when using combinations of
944 binary and unary operators. For instance:
952 because the parser has no idea — until it is too late
953 — that <token>!</token> is defined as a postfix operator,
954 not an infix one. To get the desired behavior in this case, you
959 This is the price one pays for extensibility.
962 <table id="sql-precedence-table">
963 <title>Operator Precedence (decreasing)</title>
968 <entry>Operator/Element</entry>
969 <entry>Associativity</entry>
970 <entry>Description</entry>
976 <entry><token>.</token></entry>
978 <entry>table/column name separator</entry>
982 <entry><token>::</token></entry>
984 <entry><productname>PostgreSQL</productname>-style typecast</entry>
988 <entry><token>[</token> <token>]</token></entry>
990 <entry>array element selection</entry>
994 <entry><token>-</token></entry>
996 <entry>unary minus</entry>
1000 <entry><token>^</token></entry>
1002 <entry>exponentiation</entry>
1006 <entry><token>*</token> <token>/</token> <token>%</token></entry>
1008 <entry>multiplication, division, modulo</entry>
1012 <entry><token>+</token> <token>-</token></entry>
1014 <entry>addition, subtraction</entry>
1018 <entry><token>IS</token></entry>
1020 <entry><literal>IS TRUE</>, <literal>IS FALSE</>, <literal>IS UNKNOWN</>, <literal>IS NULL</></entry>
1024 <entry><token>ISNULL</token></entry>
1026 <entry>test for null</entry>
1030 <entry><token>NOTNULL</token></entry>
1032 <entry>test for not null</entry>
1036 <entry>(any other)</entry>
1038 <entry>all other native and user-defined operators</entry>
1042 <entry><token>IN</token></entry>
1044 <entry>set membership</entry>
1048 <entry><token>BETWEEN</token></entry>
1050 <entry>range containment</entry>
1054 <entry><token>OVERLAPS</token></entry>
1056 <entry>time interval overlap</entry>
1060 <entry><token>LIKE</token> <token>ILIKE</token> <token>SIMILAR</token></entry>
1062 <entry>string pattern matching</entry>
1066 <entry><token><</token> <token>></token></entry>
1068 <entry>less than, greater than</entry>
1072 <entry><token>=</token></entry>
1073 <entry>right</entry>
1074 <entry>equality, assignment</entry>
1078 <entry><token>NOT</token></entry>
1079 <entry>right</entry>
1080 <entry>logical negation</entry>
1084 <entry><token>AND</token></entry>
1086 <entry>logical conjunction</entry>
1090 <entry><token>OR</token></entry>
1092 <entry>logical disjunction</entry>
1099 Note that the operator precedence rules also apply to user-defined
1100 operators that have the same names as the built-in operators
1101 mentioned above. For example, if you define a
1102 <quote>+</quote> operator for some custom data type it will have
1103 the same precedence as the built-in <quote>+</quote> operator, no
1104 matter what yours does.
1108 When a schema-qualified operator name is used in the
1109 <literal>OPERATOR</> syntax, as for example in:
1111 SELECT 3 OPERATOR(pg_catalog.+) 4;
1113 the <literal>OPERATOR</> construct is taken to have the default precedence
1114 shown in <xref linkend="sql-precedence-table"> for <quote>any other</> operator. This is true no matter
1115 which specific operator name appears inside <literal>OPERATOR()</>.
1120 <sect1 id="sql-expressions">
1121 <title>Value Expressions</title>
1123 <indexterm zone="sql-expressions">
1124 <primary>expression</primary>
1125 <secondary>syntax</secondary>
1128 <indexterm zone="sql-expressions">
1129 <primary>value expression</primary>
1133 <primary>scalar</primary>
1134 <see>expression</see>
1138 Value expressions are used in a variety of contexts, such
1139 as in the target list of the <command>SELECT</command> command, as
1140 new column values in <command>INSERT</command> or
1141 <command>UPDATE</command>, or in search conditions in a number of
1142 commands. The result of a value expression is sometimes called a
1143 <firstterm>scalar</firstterm>, to distinguish it from the result of
1144 a table expression (which is a table). Value expressions are
1145 therefore also called <firstterm>scalar expressions</firstterm> (or
1146 even simply <firstterm>expressions</firstterm>). The expression
1147 syntax allows the calculation of values from primitive parts using
1148 arithmetic, logical, set, and other operations.
1152 A value expression is one of the following:
1157 A constant or literal value.
1169 A positional parameter reference, in the body of a function definition
1170 or prepared statement.
1176 A subscripted expression.
1182 A field selection expression.
1188 An operator invocation.
1200 An aggregate expression.
1206 A window function call.
1224 An array constructor.
1236 Another value expression in parentheses, useful to group
1237 subexpressions and override
1238 precedence.<indexterm><primary>parenthesis</></>
1245 In addition to this list, there are a number of constructs that can
1246 be classified as an expression but do not follow any general syntax
1247 rules. These generally have the semantics of a function or
1248 operator and are explained in the appropriate location in <xref
1249 linkend="functions">. An example is the <literal>IS NULL</literal>
1254 We have already discussed constants in <xref
1255 linkend="sql-syntax-constants">. The following sections discuss
1256 the remaining options.
1260 <title>Column References</title>
1263 <primary>column reference</primary>
1267 A column can be referenced in the form
1269 <replaceable>correlation</replaceable>.<replaceable>columnname</replaceable>
1274 <replaceable>correlation</replaceable> is the name of a
1275 table (possibly qualified with a schema name), or an alias for a table
1276 defined by means of a <literal>FROM</literal> clause, or one of
1277 the key words <literal>NEW</literal> or <literal>OLD</literal>.
1278 (<literal>NEW</literal> and <literal>OLD</literal> can only appear in rewrite rules,
1279 while other correlation names can be used in any SQL statement.)
1280 The correlation name and separating dot can be omitted if the column name
1281 is unique across all the tables being used in the current query. (See also <xref linkend="queries">.)
1286 <title>Positional Parameters</title>
1289 <primary>parameter</primary>
1290 <secondary>syntax</secondary>
1294 <primary>$</primary>
1298 A positional parameter reference is used to indicate a value
1299 that is supplied externally to an SQL statement. Parameters are
1300 used in SQL function definitions and in prepared queries. Some
1301 client libraries also support specifying data values separately
1302 from the SQL command string, in which case parameters are used to
1303 refer to the out-of-line data values.
1304 The form of a parameter reference is:
1306 $<replaceable>number</replaceable>
1311 For example, consider the definition of a function,
1312 <function>dept</function>, as:
1315 CREATE FUNCTION dept(text) RETURNS dept
1316 AS $$ SELECT * FROM dept WHERE name = $1 $$
1320 Here the <literal>$1</literal> references the value of the first
1321 function argument whenever the function is invoked.
1326 <title>Subscripts</title>
1329 <primary>subscript</primary>
1333 If an expression yields a value of an array type, then a specific
1334 element of the array value can be extracted by writing
1336 <replaceable>expression</replaceable>[<replaceable>subscript</replaceable>]
1338 or multiple adjacent elements (an <quote>array slice</>) can be extracted
1341 <replaceable>expression</replaceable>[<replaceable>lower_subscript</replaceable>:<replaceable>upper_subscript</replaceable>]
1343 (Here, the brackets <literal>[ ]</literal> are meant to appear literally.)
1344 Each <replaceable>subscript</replaceable> is itself an expression,
1345 which must yield an integer value.
1349 In general the array <replaceable>expression</replaceable> must be
1350 parenthesized, but the parentheses can be omitted when the expression
1351 to be subscripted is just a column reference or positional parameter.
1352 Also, multiple subscripts can be concatenated when the original array
1353 is multidimensional.
1357 mytable.arraycolumn[4]
1358 mytable.two_d_column[17][34]
1360 (arrayfunction(a,b))[42]
1363 The parentheses in the last example are required.
1364 See <xref linkend="arrays"> for more about arrays.
1369 <title>Field Selection</title>
1372 <primary>field selection</primary>
1376 If an expression yields a value of a composite type (row type), then a
1377 specific field of the row can be extracted by writing
1379 <replaceable>expression</replaceable>.<replaceable>fieldname</replaceable>
1384 In general the row <replaceable>expression</replaceable> must be
1385 parenthesized, but the parentheses can be omitted when the expression
1386 to be selected from is just a table reference or positional parameter.
1392 (rowfunction(a,b)).col3
1395 (Thus, a qualified column reference is actually just a special case
1396 of the field selection syntax.) An important special case is
1397 extracting a field from a table column that is of a composite type:
1400 (compositecol).somefield
1401 (mytable.compositecol).somefield
1404 The parentheses are required here to show that
1405 <structfield>compositecol</> is a column name not a table name,
1406 or that <structname>mytable</> is a table name not a schema name
1412 <title>Operator Invocations</title>
1415 <primary>operator</primary>
1416 <secondary>invocation</secondary>
1420 There are three possible syntaxes for an operator invocation:
1422 <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> <replaceable>expression</replaceable> (binary infix operator)</member>
1423 <member><replaceable>operator</replaceable> <replaceable>expression</replaceable> (unary prefix operator)</member>
1424 <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> (unary postfix operator)</member>
1426 where the <replaceable>operator</replaceable> token follows the syntax
1427 rules of <xref linkend="sql-syntax-operators">, or is one of the
1428 key words <token>AND</token>, <token>OR</token>, and
1429 <token>NOT</token>, or is a qualified operator name in the form
1431 <literal>OPERATOR(</><replaceable>schema</><literal>.</><replaceable>operatorname</><literal>)</>
1433 Which particular operators exist and whether
1434 they are unary or binary depends on what operators have been
1435 defined by the system or the user. <xref linkend="functions">
1436 describes the built-in operators.
1441 <title>Function Calls</title>
1444 <primary>function</primary>
1445 <secondary>invocation</secondary>
1449 The syntax for a function call is the name of a function
1450 (possibly qualified with a schema name), followed by its argument list
1451 enclosed in parentheses:
1454 <replaceable>function_name</replaceable> (<optional><replaceable>expression</replaceable> <optional>, <replaceable>expression</replaceable> ... </optional></optional> )
1459 For example, the following computes the square root of 2:
1466 The list of built-in functions is in <xref linkend="functions">.
1467 Other functions can be added by the user.
1471 <sect2 id="syntax-aggregates">
1472 <title>Aggregate Expressions</title>
1474 <indexterm zone="syntax-aggregates">
1475 <primary>aggregate function</primary>
1476 <secondary>invocation</secondary>
1480 An <firstterm>aggregate expression</firstterm> represents the
1481 application of an aggregate function across the rows selected by a
1482 query. An aggregate function reduces multiple inputs to a single
1483 output value, such as the sum or average of the inputs. The
1484 syntax of an aggregate expression is one of the following:
1487 <replaceable>aggregate_name</replaceable> (<replaceable>expression</replaceable> [ , ... ] )
1488 <replaceable>aggregate_name</replaceable> (ALL <replaceable>expression</replaceable> [ , ... ] )
1489 <replaceable>aggregate_name</replaceable> (DISTINCT <replaceable>expression</replaceable>)
1490 <replaceable>aggregate_name</replaceable> ( * )
1493 where <replaceable>aggregate_name</replaceable> is a previously
1494 defined aggregate (possibly qualified with a schema name), and
1495 <replaceable>expression</replaceable> is
1496 any value expression that does not itself contain an aggregate
1497 expression or a window function call.
1501 The first form of aggregate expression invokes the aggregate
1502 across all input rows for which the given expression(s) yield
1503 non-null values. (Actually, it is up to the aggregate function
1504 whether to ignore null values or not — but all the standard ones do.)
1505 The second form is the same as the first, since
1506 <literal>ALL</literal> is the default. The third form invokes the
1507 aggregate for all distinct non-null values of the expressions found
1508 in the input rows. The last form invokes the aggregate once for
1509 each input row regardless of null or non-null values; since no
1510 particular input value is specified, it is generally only useful
1511 for the <function>count(*)</function> aggregate function.
1515 For example, <literal>count(*)</literal> yields the total number
1516 of input rows; <literal>count(f1)</literal> yields the number of
1517 input rows in which <literal>f1</literal> is non-null;
1518 <literal>count(distinct f1)</literal> yields the number of
1519 distinct non-null values of <literal>f1</literal>.
1523 The predefined aggregate functions are described in <xref
1524 linkend="functions-aggregate">. Other aggregate functions can be added
1529 An aggregate expression can only appear in the result list or
1530 <literal>HAVING</> clause of a <command>SELECT</> command.
1531 It is forbidden in other clauses, such as <literal>WHERE</>,
1532 because those clauses are logically evaluated before the results
1533 of aggregates are formed.
1537 When an aggregate expression appears in a subquery (see
1538 <xref linkend="sql-syntax-scalar-subqueries"> and
1539 <xref linkend="functions-subquery">), the aggregate is normally
1540 evaluated over the rows of the subquery. But an exception occurs
1541 if the aggregate's arguments contain only outer-level variables:
1542 the aggregate then belongs to the nearest such outer level, and is
1543 evaluated over the rows of that query. The aggregate expression
1544 as a whole is then an outer reference for the subquery it appears in,
1545 and acts as a constant over any one evaluation of that subquery.
1546 The restriction about
1547 appearing only in the result list or <literal>HAVING</> clause
1548 applies with respect to the query level that the aggregate belongs to.
1553 <productname>PostgreSQL</productname> currently does not support
1554 <literal>DISTINCT</> with more than one input expression.
1559 <sect2 id="syntax-window-functions">
1560 <title>Window Function Calls</title>
1562 <indexterm zone="syntax-window-functions">
1563 <primary>window function</primary>
1564 <secondary>invocation</secondary>
1567 <indexterm zone="syntax-window-functions">
1568 <primary>OVER clause</primary>
1572 A <firstterm>window function call</firstterm> represents the application
1573 of an aggregate-like function over some portion of the rows selected
1574 by a query. Unlike regular aggregate function calls, this is not tied
1575 to grouping of the selected rows into a single output row — each
1576 row remains separate in the query output. However the window function
1577 is able to scan all the rows that would be part of the current row's
1578 group according to the grouping specification (<literal>PARTITION BY</>
1579 list) of the window function call.
1580 The syntax of a window function call is one of the following:
1583 <replaceable>function_name</replaceable> (<optional><replaceable>expression</replaceable> <optional>, <replaceable>expression</replaceable> ... </optional></optional>) OVER ( <replaceable class="parameter">window_definition</replaceable> )
1584 <replaceable>function_name</replaceable> (<optional><replaceable>expression</replaceable> <optional>, <replaceable>expression</replaceable> ... </optional></optional>) OVER <replaceable>window_name</replaceable>
1585 <replaceable>function_name</replaceable> ( * ) OVER ( <replaceable class="parameter">window_definition</replaceable> )
1586 <replaceable>function_name</replaceable> ( * ) OVER <replaceable>window_name</replaceable>
1588 where <replaceable class="parameter">window_definition</replaceable>
1591 [ <replaceable class="parameter">existing_window_name</replaceable> ]
1592 [ PARTITION BY <replaceable class="parameter">expression</replaceable> [, ...] ]
1593 [ ORDER BY <replaceable class="parameter">expression</replaceable> [ ASC | DESC | USING <replaceable class="parameter">operator</replaceable> ] [ NULLS { FIRST | LAST } ] [, ...] ]
1594 [ <replaceable class="parameter">frame_clause</replaceable> ]
1596 and the optional <replaceable class="parameter">frame_clause</replaceable>
1599 RANGE UNBOUNDED PRECEDING
1600 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
1601 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
1602 ROWS UNBOUNDED PRECEDING
1603 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
1604 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
1607 Here, <replaceable>expression</replaceable> represents any value
1608 expression that does not itself contain window function calls.
1609 The <literal>PARTITION BY</> and <literal>ORDER BY</> lists have
1610 essentially the same syntax and semantics as <literal>GROUP BY</>
1611 and <literal>ORDER BY</> clauses of the whole query.
1612 <replaceable>window_name</replaceable> is a reference to a named window
1613 specification defined in the query's <literal>WINDOW</literal> clause.
1614 Named window specifications are usually referenced with just
1615 <literal>OVER</> <replaceable>window_name</replaceable>, but it is
1616 also possible to write a window name inside the parentheses and then
1617 optionally supply an ordering clause and/or frame clause (the referenced
1618 window must lack these clauses, if they are supplied here).
1619 This latter syntax follows the same rules as modifying an existing
1620 window name within the <literal>WINDOW</literal> clause; see the
1621 <xref linkend="sql-select" endterm="sql-select-title"> reference
1626 The <replaceable class="parameter">frame_clause</replaceable> specifies
1627 the set of rows constituting the <firstterm>window frame</>, for those
1628 window functions that act on the frame instead of the whole partition.
1629 The default framing option is <literal>RANGE UNBOUNDED PRECEDING</>,
1630 which is the same as <literal>RANGE BETWEEN UNBOUNDED PRECEDING AND
1631 CURRENT ROW</>; it selects rows up through the current row's last
1632 peer in the <literal>ORDER BY</> ordering (which means all rows if
1633 there is no <literal>ORDER BY</>). The options
1634 <literal>RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING</> and
1635 <literal>ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING</>
1636 are also equivalent: they always select all rows in the partition.
1637 Lastly, <literal>ROWS UNBOUNDED PRECEDING</> or its verbose equivalent
1638 <literal>ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW</> select
1639 all rows up through the current row (regardless of duplicates).
1640 Beware that this option can produce implementation-dependent results
1641 if the <literal>ORDER BY</> ordering does not order the rows uniquely.
1645 The built-in window functions are described in <xref
1646 linkend="functions-window-table">. Other window functions can be added by
1647 the user. Also, any built-in or user-defined aggregate function can be
1648 used as a window function.
1652 The syntaxes using <literal>*</> are used for calling parameter-less
1653 aggregate functions as window functions, for example
1654 <literal>count(*) OVER (PARTITION BY x ORDER BY y)</>.
1655 <literal>*</> is customarily not used for non-aggregate window functions.
1656 Aggregate window functions, unlike normal aggregate functions, do not
1657 allow <literal>DISTINCT</> to be used within the function argument list.
1661 Window function calls are permitted only in the <literal>SELECT</literal>
1662 list and the <literal>ORDER BY</> clause of the query.
1666 More information about window functions can be found in
1667 <xref linkend="tutorial-window"> and
1668 <xref linkend="queries-window">.
1672 <sect2 id="sql-syntax-type-casts">
1673 <title>Type Casts</title>
1676 <primary>data type</primary>
1677 <secondary>type cast</secondary>
1681 <primary>type cast</primary>
1685 A type cast specifies a conversion from one data type to another.
1686 <productname>PostgreSQL</productname> accepts two equivalent syntaxes
1689 CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable> )
1690 <replaceable>expression</replaceable>::<replaceable>type</replaceable>
1692 The <literal>CAST</> syntax conforms to SQL; the syntax with
1693 <literal>::</literal> is historical <productname>PostgreSQL</productname>
1698 When a cast is applied to a value expression of a known type, it
1699 represents a run-time type conversion. The cast will succeed only
1700 if a suitable type conversion operation has been defined. Notice that this
1701 is subtly different from the use of casts with constants, as shown in
1702 <xref linkend="sql-syntax-constants-generic">. A cast applied to an
1703 unadorned string literal represents the initial assignment of a type
1704 to a literal constant value, and so it will succeed for any type
1705 (if the contents of the string literal are acceptable input syntax for the
1710 An explicit type cast can usually be omitted if there is no ambiguity as
1711 to the type that a value expression must produce (for example, when it is
1712 assigned to a table column); the system will automatically apply a
1713 type cast in such cases. However, automatic casting is only done for
1714 casts that are marked <quote>OK to apply implicitly</>
1715 in the system catalogs. Other casts must be invoked with
1716 explicit casting syntax. This restriction is intended to prevent
1717 surprising conversions from being applied silently.
1721 It is also possible to specify a type cast using a function-like
1724 <replaceable>typename</replaceable> ( <replaceable>expression</replaceable> )
1726 However, this only works for types whose names are also valid as
1727 function names. For example, <literal>double precision</literal>
1728 cannot be used this way, but the equivalent <literal>float8</literal>
1729 can. Also, the names <literal>interval</>, <literal>time</>, and
1730 <literal>timestamp</> can only be used in this fashion if they are
1731 double-quoted, because of syntactic conflicts. Therefore, the use of
1732 the function-like cast syntax leads to inconsistencies and should
1733 probably be avoided in new applications.
1738 The function-like syntax is in fact just a function call. When
1739 one of the two standard cast syntaxes is used to do a run-time
1740 conversion, it will internally invoke a registered function to
1741 perform the conversion. By convention, these conversion functions
1742 have the same name as their output type, and thus the <quote>function-like
1743 syntax</> is nothing more than a direct invocation of the underlying
1744 conversion function. Obviously, this is not something that a portable
1745 application should rely on. For further details see
1746 <xref linkend="sql-createcast" endterm="sql-createcast-title">.
1751 <sect2 id="sql-syntax-scalar-subqueries">
1752 <title>Scalar Subqueries</title>
1755 <primary>subquery</primary>
1759 A scalar subquery is an ordinary
1760 <command>SELECT</command> query in parentheses that returns exactly one
1761 row with one column. (See <xref linkend="queries"> for information about writing queries.)
1762 The <command>SELECT</command> query is executed
1763 and the single returned value is used in the surrounding value expression.
1764 It is an error to use a query that
1765 returns more than one row or more than one column as a scalar subquery.
1766 (But if, during a particular execution, the subquery returns no rows,
1767 there is no error; the scalar result is taken to be null.)
1768 The subquery can refer to variables from the surrounding query,
1769 which will act as constants during any one evaluation of the subquery.
1770 See also <xref linkend="functions-subquery"> for other expressions involving subqueries.
1774 For example, the following finds the largest city population in each
1777 SELECT name, (SELECT max(pop) FROM cities WHERE cities.state = states.name)
1783 <sect2 id="sql-syntax-array-constructors">
1784 <title>Array Constructors</title>
1787 <primary>array</primary>
1788 <secondary>constructor</secondary>
1792 <primary>ARRAY</primary>
1796 An array constructor is an expression that builds an
1797 array value from values for its member elements. A simple array
1799 consists of the key word <literal>ARRAY</literal>, a left square bracket
1800 <literal>[</>, a list of expressions (separated by commas) for the
1801 array element values, and finally a right square bracket <literal>]</>.
1804 SELECT ARRAY[1,2,3+4];
1811 the array element type is the common type of the member expressions,
1812 determined using the same rules as for <literal>UNION</> or
1813 <literal>CASE</> constructs (see <xref linkend="typeconv-union-case">).
1814 You can override this by explicitly casting the array constructor to the
1815 desired type, for example:
1817 SELECT ARRAY[1,2,22.7]::integer[];
1823 This has the same effect as casting each expression to the array
1824 element type individually.
1825 For more on casting, see <xref linkend="sql-syntax-type-casts">.
1829 Multidimensional array values can be built by nesting array
1831 In the inner constructors, the key word <literal>ARRAY</literal> can
1832 be omitted. For example, these produce the same result:
1835 SELECT ARRAY[ARRAY[1,2], ARRAY[3,4]];
1841 SELECT ARRAY[[1,2],[3,4]];
1848 Since multidimensional arrays must be rectangular, inner constructors
1849 at the same level must produce sub-arrays of identical dimensions.
1850 Any cast applied to the outer <literal>ARRAY</> constructor propagates
1851 automatically to all the inner constructors.
1855 Multidimensional array constructor elements can be anything yielding
1856 an array of the proper kind, not only a sub-<literal>ARRAY</> construct.
1859 CREATE TABLE arr(f1 int[], f2 int[]);
1861 INSERT INTO arr VALUES (ARRAY[[1,2],[3,4]], ARRAY[[5,6],[7,8]]);
1863 SELECT ARRAY[f1, f2, '{{9,10},{11,12}}'::int[]] FROM arr;
1865 ------------------------------------------------
1866 {{{1,2},{3,4}},{{5,6},{7,8}},{{9,10},{11,12}}}
1872 You can construct an empty array, but since it's impossible to have an
1873 array with no type, you must explicitly cast your empty array to the
1874 desired type. For example:
1876 SELECT ARRAY[]::integer[];
1885 It is also possible to construct an array from the results of a
1886 subquery. In this form, the array constructor is written with the
1887 key word <literal>ARRAY</literal> followed by a parenthesized (not
1888 bracketed) subquery. For example:
1890 SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
1892 -------------------------------------------------------------
1893 {2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
1896 The subquery must return a single column. The resulting
1897 one-dimensional array will have an element for each row in the
1898 subquery result, with an element type matching that of the
1899 subquery's output column.
1903 The subscripts of an array value built with <literal>ARRAY</literal>
1904 always begin with one. For more information about arrays, see
1905 <xref linkend="arrays">.
1910 <sect2 id="sql-syntax-row-constructors">
1911 <title>Row Constructors</title>
1914 <primary>composite type</primary>
1915 <secondary>constructor</secondary>
1919 <primary>row type</primary>
1920 <secondary>constructor</secondary>
1924 <primary>ROW</primary>
1928 A row constructor is an expression that builds a row value (also
1929 called a composite value) from values
1930 for its member fields. A row constructor consists of the key word
1931 <literal>ROW</literal>, a left parenthesis, zero or more
1932 expressions (separated by commas) for the row field values, and finally
1933 a right parenthesis. For example:
1935 SELECT ROW(1,2.5,'this is a test');
1937 The key word <literal>ROW</> is optional when there is more than one
1938 expression in the list.
1942 A row constructor can include the syntax
1943 <replaceable>rowvalue</replaceable><literal>.*</literal>,
1944 which will be expanded to a list of the elements of the row value,
1945 just as occurs when the <literal>.*</> syntax is used at the top level
1946 of a <command>SELECT</> list. For example, if table <literal>t</> has
1947 columns <literal>f1</> and <literal>f2</>, these are the same:
1949 SELECT ROW(t.*, 42) FROM t;
1950 SELECT ROW(t.f1, t.f2, 42) FROM t;
1956 Before <productname>PostgreSQL</productname> 8.2, the
1957 <literal>.*</literal> syntax was not expanded, so that writing
1958 <literal>ROW(t.*, 42)</> created a two-field row whose first field
1959 was another row value. The new behavior is usually more useful.
1960 If you need the old behavior of nested row values, write the inner
1961 row value without <literal>.*</literal>, for instance
1962 <literal>ROW(t, 42)</>.
1967 By default, the value created by a <literal>ROW</> expression is of
1968 an anonymous record type. If necessary, it can be cast to a named
1969 composite type — either the row type of a table, or a composite type
1970 created with <command>CREATE TYPE AS</>. An explicit cast might be needed
1971 to avoid ambiguity. For example:
1973 CREATE TABLE mytable(f1 int, f2 float, f3 text);
1975 CREATE FUNCTION getf1(mytable) RETURNS int AS 'SELECT $1.f1' LANGUAGE SQL;
1977 -- No cast needed since only one getf1() exists
1978 SELECT getf1(ROW(1,2.5,'this is a test'));
1984 CREATE TYPE myrowtype AS (f1 int, f2 text, f3 numeric);
1986 CREATE FUNCTION getf1(myrowtype) RETURNS int AS 'SELECT $1.f1' LANGUAGE SQL;
1988 -- Now we need a cast to indicate which function to call:
1989 SELECT getf1(ROW(1,2.5,'this is a test'));
1990 ERROR: function getf1(record) is not unique
1992 SELECT getf1(ROW(1,2.5,'this is a test')::mytable);
1998 SELECT getf1(CAST(ROW(11,'this is a test',2.5) AS myrowtype));
2007 Row constructors can be used to build composite values to be stored
2008 in a composite-type table column, or to be passed to a function that
2009 accepts a composite parameter. Also,
2010 it is possible to compare two row values or test a row with
2011 <literal>IS NULL</> or <literal>IS NOT NULL</>, for example:
2013 SELECT ROW(1,2.5,'this is a test') = ROW(1, 3, 'not the same');
2015 SELECT ROW(table.*) IS NULL FROM table; -- detect all-null rows
2017 For more detail see <xref linkend="functions-comparisons">.
2018 Row constructors can also be used in connection with subqueries,
2019 as discussed in <xref linkend="functions-subquery">.
2024 <sect2 id="syntax-express-eval">
2025 <title>Expression Evaluation Rules</title>
2028 <primary>expression</primary>
2029 <secondary>order of evaluation</secondary>
2033 The order of evaluation of subexpressions is not defined. In
2034 particular, the inputs of an operator or function are not necessarily
2035 evaluated left-to-right or in any other fixed order.
2039 Furthermore, if the result of an expression can be determined by
2040 evaluating only some parts of it, then other subexpressions
2041 might not be evaluated at all. For instance, if one wrote:
2043 SELECT true OR somefunc();
2045 then <literal>somefunc()</literal> would (probably) not be called
2046 at all. The same would be the case if one wrote:
2048 SELECT somefunc() OR true;
2050 Note that this is not the same as the left-to-right
2051 <quote>short-circuiting</quote> of Boolean operators that is found
2052 in some programming languages.
2056 As a consequence, it is unwise to use functions with side effects
2057 as part of complex expressions. It is particularly dangerous to
2058 rely on side effects or evaluation order in <literal>WHERE</> and <literal>HAVING</> clauses,
2059 since those clauses are extensively reprocessed as part of
2060 developing an execution plan. Boolean
2061 expressions (<literal>AND</>/<literal>OR</>/<literal>NOT</> combinations) in those clauses can be reorganized
2062 in any manner allowed by the laws of Boolean algebra.
2066 When it is essential to force evaluation order, a <literal>CASE</>
2067 construct (see <xref linkend="functions-conditional">) can be
2068 used. For example, this is an untrustworthy way of trying to
2069 avoid division by zero in a <literal>WHERE</> clause:
2071 SELECT ... WHERE x > 0 AND y/x > 1.5;
2075 SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;
2077 A <literal>CASE</> construct used in this fashion will defeat optimization
2078 attempts, so it should only be done when necessary. (In this particular
2079 example, it would be better to sidestep the problem by writing
2080 <literal>y > 1.5*x</> instead.)