1 <!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.124 2008/10/29 08:04:52 petere 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
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
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.
1218 An array constructor.
1230 Another value expression in parentheses, useful to group
1231 subexpressions and override
1232 precedence.<indexterm><primary>parenthesis</></>
1239 In addition to this list, there are a number of constructs that can
1240 be classified as an expression but do not follow any general syntax
1241 rules. These generally have the semantics of a function or
1242 operator and are explained in the appropriate location in <xref
1243 linkend="functions">. An example is the <literal>IS NULL</literal>
1248 We have already discussed constants in <xref
1249 linkend="sql-syntax-constants">. The following sections discuss
1250 the remaining options.
1254 <title>Column References</title>
1257 <primary>column reference</primary>
1261 A column can be referenced in the form
1263 <replaceable>correlation</replaceable>.<replaceable>columnname</replaceable>
1268 <replaceable>correlation</replaceable> is the name of a
1269 table (possibly qualified with a schema name), or an alias for a table
1270 defined by means of a <literal>FROM</literal> clause, or one of
1271 the key words <literal>NEW</literal> or <literal>OLD</literal>.
1272 (<literal>NEW</literal> and <literal>OLD</literal> can only appear in rewrite rules,
1273 while other correlation names can be used in any SQL statement.)
1274 The correlation name and separating dot can be omitted if the column name
1275 is unique across all the tables being used in the current query. (See also <xref linkend="queries">.)
1280 <title>Positional Parameters</title>
1283 <primary>parameter</primary>
1284 <secondary>syntax</secondary>
1288 <primary>$</primary>
1292 A positional parameter reference is used to indicate a value
1293 that is supplied externally to an SQL statement. Parameters are
1294 used in SQL function definitions and in prepared queries. Some
1295 client libraries also support specifying data values separately
1296 from the SQL command string, in which case parameters are used to
1297 refer to the out-of-line data values.
1298 The form of a parameter reference is:
1300 $<replaceable>number</replaceable>
1305 For example, consider the definition of a function,
1306 <function>dept</function>, as:
1309 CREATE FUNCTION dept(text) RETURNS dept
1310 AS $$ SELECT * FROM dept WHERE name = $1 $$
1314 Here the <literal>$1</literal> references the value of the first
1315 function argument whenever the function is invoked.
1320 <title>Subscripts</title>
1323 <primary>subscript</primary>
1327 If an expression yields a value of an array type, then a specific
1328 element of the array value can be extracted by writing
1330 <replaceable>expression</replaceable>[<replaceable>subscript</replaceable>]
1332 or multiple adjacent elements (an <quote>array slice</>) can be extracted
1335 <replaceable>expression</replaceable>[<replaceable>lower_subscript</replaceable>:<replaceable>upper_subscript</replaceable>]
1337 (Here, the brackets <literal>[ ]</literal> are meant to appear literally.)
1338 Each <replaceable>subscript</replaceable> is itself an expression,
1339 which must yield an integer value.
1343 In general the array <replaceable>expression</replaceable> must be
1344 parenthesized, but the parentheses can be omitted when the expression
1345 to be subscripted is just a column reference or positional parameter.
1346 Also, multiple subscripts can be concatenated when the original array
1347 is multidimensional.
1351 mytable.arraycolumn[4]
1352 mytable.two_d_column[17][34]
1354 (arrayfunction(a,b))[42]
1357 The parentheses in the last example are required.
1358 See <xref linkend="arrays"> for more about arrays.
1363 <title>Field Selection</title>
1366 <primary>field selection</primary>
1370 If an expression yields a value of a composite type (row type), then a
1371 specific field of the row can be extracted by writing
1373 <replaceable>expression</replaceable>.<replaceable>fieldname</replaceable>
1378 In general the row <replaceable>expression</replaceable> must be
1379 parenthesized, but the parentheses can be omitted when the expression
1380 to be selected from is just a table reference or positional parameter.
1386 (rowfunction(a,b)).col3
1389 (Thus, a qualified column reference is actually just a special case
1390 of the field selection syntax.)
1395 <title>Operator Invocations</title>
1398 <primary>operator</primary>
1399 <secondary>invocation</secondary>
1403 There are three possible syntaxes for an operator invocation:
1405 <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> <replaceable>expression</replaceable> (binary infix operator)</member>
1406 <member><replaceable>operator</replaceable> <replaceable>expression</replaceable> (unary prefix operator)</member>
1407 <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> (unary postfix operator)</member>
1409 where the <replaceable>operator</replaceable> token follows the syntax
1410 rules of <xref linkend="sql-syntax-operators">, or is one of the
1411 key words <token>AND</token>, <token>OR</token>, and
1412 <token>NOT</token>, or is a qualified operator name in the form
1414 <literal>OPERATOR(</><replaceable>schema</><literal>.</><replaceable>operatorname</><literal>)</>
1416 Which particular operators exist and whether
1417 they are unary or binary depends on what operators have been
1418 defined by the system or the user. <xref linkend="functions">
1419 describes the built-in operators.
1424 <title>Function Calls</title>
1427 <primary>function</primary>
1428 <secondary>invocation</secondary>
1432 The syntax for a function call is the name of a function
1433 (possibly qualified with a schema name), followed by its argument list
1434 enclosed in parentheses:
1437 <replaceable>function</replaceable> (<optional><replaceable>expression</replaceable> <optional>, <replaceable>expression</replaceable> ... </optional></optional> )
1442 For example, the following computes the square root of 2:
1449 The list of built-in functions is in <xref linkend="functions">.
1450 Other functions can be added by the user.
1454 <sect2 id="syntax-aggregates">
1455 <title>Aggregate Expressions</title>
1457 <indexterm zone="syntax-aggregates">
1458 <primary>aggregate function</primary>
1459 <secondary>invocation</secondary>
1463 An <firstterm>aggregate expression</firstterm> represents the
1464 application of an aggregate function across the rows selected by a
1465 query. An aggregate function reduces multiple inputs to a single
1466 output value, such as the sum or average of the inputs. The
1467 syntax of an aggregate expression is one of the following:
1470 <replaceable>aggregate_name</replaceable> (<replaceable>expression</replaceable> [ , ... ] )
1471 <replaceable>aggregate_name</replaceable> (ALL <replaceable>expression</replaceable> [ , ... ] )
1472 <replaceable>aggregate_name</replaceable> (DISTINCT <replaceable>expression</replaceable> [ , ... ] )
1473 <replaceable>aggregate_name</replaceable> ( * )
1476 where <replaceable>aggregate_name</replaceable> is a previously
1477 defined aggregate (possibly qualified with a schema name), and
1478 <replaceable>expression</replaceable> is
1479 any value expression that does not itself contain an aggregate
1484 The first form of aggregate expression invokes the aggregate
1485 across all input rows for which the given expression(s) yield
1486 non-null values. (Actually, it is up to the aggregate function
1487 whether to ignore null values or not — but all the standard ones do.)
1488 The second form is the same as the first, since
1489 <literal>ALL</literal> is the default. The third form invokes the
1490 aggregate for all distinct non-null values of the expressions found
1491 in the input rows. The last form invokes the aggregate once for
1492 each input row regardless of null or non-null values; since no
1493 particular input value is specified, it is generally only useful
1494 for the <function>count(*)</function> aggregate function.
1498 For example, <literal>count(*)</literal> yields the total number
1499 of input rows; <literal>count(f1)</literal> yields the number of
1500 input rows in which <literal>f1</literal> is non-null;
1501 <literal>count(distinct f1)</literal> yields the number of
1502 distinct non-null values of <literal>f1</literal>.
1506 The predefined aggregate functions are described in <xref
1507 linkend="functions-aggregate">. Other aggregate functions can be added
1512 An aggregate expression can only appear in the result list or
1513 <literal>HAVING</> clause of a <command>SELECT</> command.
1514 It is forbidden in other clauses, such as <literal>WHERE</>,
1515 because those clauses are logically evaluated before the results
1516 of aggregates are formed.
1520 When an aggregate expression appears in a subquery (see
1521 <xref linkend="sql-syntax-scalar-subqueries"> and
1522 <xref linkend="functions-subquery">), the aggregate is normally
1523 evaluated over the rows of the subquery. But an exception occurs
1524 if the aggregate's arguments contain only outer-level variables:
1525 the aggregate then belongs to the nearest such outer level, and is
1526 evaluated over the rows of that query. The aggregate expression
1527 as a whole is then an outer reference for the subquery it appears in,
1528 and acts as a constant over any one evaluation of that subquery.
1529 The restriction about
1530 appearing only in the result list or <literal>HAVING</> clause
1531 applies with respect to the query level that the aggregate belongs to.
1536 <productname>PostgreSQL</productname> currently does not support
1537 <literal>DISTINCT</> with more than one input expression.
1542 <sect2 id="sql-syntax-type-casts">
1543 <title>Type Casts</title>
1546 <primary>data type</primary>
1547 <secondary>type cast</secondary>
1551 <primary>type cast</primary>
1555 A type cast specifies a conversion from one data type to another.
1556 <productname>PostgreSQL</productname> accepts two equivalent syntaxes
1559 CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable> )
1560 <replaceable>expression</replaceable>::<replaceable>type</replaceable>
1562 The <literal>CAST</> syntax conforms to SQL; the syntax with
1563 <literal>::</literal> is historical <productname>PostgreSQL</productname>
1568 When a cast is applied to a value expression of a known type, it
1569 represents a run-time type conversion. The cast will succeed only
1570 if a suitable type conversion operation has been defined. Notice that this
1571 is subtly different from the use of casts with constants, as shown in
1572 <xref linkend="sql-syntax-constants-generic">. A cast applied to an
1573 unadorned string literal represents the initial assignment of a type
1574 to a literal constant value, and so it will succeed for any type
1575 (if the contents of the string literal are acceptable input syntax for the
1580 An explicit type cast can usually be omitted if there is no ambiguity as
1581 to the type that a value expression must produce (for example, when it is
1582 assigned to a table column); the system will automatically apply a
1583 type cast in such cases. However, automatic casting is only done for
1584 casts that are marked <quote>OK to apply implicitly</>
1585 in the system catalogs. Other casts must be invoked with
1586 explicit casting syntax. This restriction is intended to prevent
1587 surprising conversions from being applied silently.
1591 It is also possible to specify a type cast using a function-like
1594 <replaceable>typename</replaceable> ( <replaceable>expression</replaceable> )
1596 However, this only works for types whose names are also valid as
1597 function names. For example, <literal>double precision</literal>
1598 cannot be used this way, but the equivalent <literal>float8</literal>
1599 can. Also, the names <literal>interval</>, <literal>time</>, and
1600 <literal>timestamp</> can only be used in this fashion if they are
1601 double-quoted, because of syntactic conflicts. Therefore, the use of
1602 the function-like cast syntax leads to inconsistencies and should
1603 probably be avoided in new applications.
1608 The function-like syntax is in fact just a function call. When
1609 one of the two standard cast syntaxes is used to do a run-time
1610 conversion, it will internally invoke a registered function to
1611 perform the conversion. By convention, these conversion functions
1612 have the same name as their output type, and thus the <quote>function-like
1613 syntax</> is nothing more than a direct invocation of the underlying
1614 conversion function. Obviously, this is not something that a portable
1615 application should rely on. For further details see
1616 <xref linkend="sql-createcast" endterm="sql-createcast-title">.
1621 <sect2 id="sql-syntax-scalar-subqueries">
1622 <title>Scalar Subqueries</title>
1625 <primary>subquery</primary>
1629 A scalar subquery is an ordinary
1630 <command>SELECT</command> query in parentheses that returns exactly one
1631 row with one column. (See <xref linkend="queries"> for information about writing queries.)
1632 The <command>SELECT</command> query is executed
1633 and the single returned value is used in the surrounding value expression.
1634 It is an error to use a query that
1635 returns more than one row or more than one column as a scalar subquery.
1636 (But if, during a particular execution, the subquery returns no rows,
1637 there is no error; the scalar result is taken to be null.)
1638 The subquery can refer to variables from the surrounding query,
1639 which will act as constants during any one evaluation of the subquery.
1640 See also <xref linkend="functions-subquery"> for other expressions involving subqueries.
1644 For example, the following finds the largest city population in each
1647 SELECT name, (SELECT max(pop) FROM cities WHERE cities.state = states.name)
1653 <sect2 id="sql-syntax-array-constructors">
1654 <title>Array Constructors</title>
1657 <primary>array</primary>
1658 <secondary>constructor</secondary>
1662 <primary>ARRAY</primary>
1666 An array constructor is an expression that builds an
1667 array value from values for its member elements. A simple array
1669 consists of the key word <literal>ARRAY</literal>, a left square bracket
1670 <literal>[</>, a list of expressions (separated by commas) for the
1671 array element values, and finally a right square bracket <literal>]</>.
1674 SELECT ARRAY[1,2,3+4];
1681 the array element type is the common type of the member expressions,
1682 determined using the same rules as for <literal>UNION</> or
1683 <literal>CASE</> constructs (see <xref linkend="typeconv-union-case">).
1684 You can override this by explicitly casting the array constructor to the
1685 desired type, for example:
1687 SELECT ARRAY[1,2,22.7]::integer[];
1693 This has the same effect as casting each expression to the array
1694 element type individually.
1695 For more on casting, see <xref linkend="sql-syntax-type-casts">.
1699 Multidimensional array values can be built by nesting array
1701 In the inner constructors, the key word <literal>ARRAY</literal> can
1702 be omitted. For example, these produce the same result:
1705 SELECT ARRAY[ARRAY[1,2], ARRAY[3,4]];
1711 SELECT ARRAY[[1,2],[3,4]];
1718 Since multidimensional arrays must be rectangular, inner constructors
1719 at the same level must produce sub-arrays of identical dimensions.
1720 Any cast applied to the outer <literal>ARRAY</> constructor propagates
1721 automatically to all the inner constructors.
1725 Multidimensional array constructor elements can be anything yielding
1726 an array of the proper kind, not only a sub-<literal>ARRAY</> construct.
1729 CREATE TABLE arr(f1 int[], f2 int[]);
1731 INSERT INTO arr VALUES (ARRAY[[1,2],[3,4]], ARRAY[[5,6],[7,8]]);
1733 SELECT ARRAY[f1, f2, '{{9,10},{11,12}}'::int[]] FROM arr;
1735 ------------------------------------------------
1736 {{{1,2},{3,4}},{{5,6},{7,8}},{{9,10},{11,12}}}
1742 You can construct an empty array, but since it's impossible to have an
1743 array with no type, you must explicitly cast your empty array to the
1744 desired type. For example:
1746 SELECT ARRAY[]::integer[];
1755 It is also possible to construct an array from the results of a
1756 subquery. In this form, the array constructor is written with the
1757 key word <literal>ARRAY</literal> followed by a parenthesized (not
1758 bracketed) subquery. For example:
1760 SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
1762 -------------------------------------------------------------
1763 {2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
1766 The subquery must return a single column. The resulting
1767 one-dimensional array will have an element for each row in the
1768 subquery result, with an element type matching that of the
1769 subquery's output column.
1773 The subscripts of an array value built with <literal>ARRAY</literal>
1774 always begin with one. For more information about arrays, see
1775 <xref linkend="arrays">.
1780 <sect2 id="sql-syntax-row-constructors">
1781 <title>Row Constructors</title>
1784 <primary>composite type</primary>
1785 <secondary>constructor</secondary>
1789 <primary>row type</primary>
1790 <secondary>constructor</secondary>
1794 <primary>ROW</primary>
1798 A row constructor is an expression that builds a row value (also
1799 called a composite value) from values
1800 for its member fields. A row constructor consists of the key word
1801 <literal>ROW</literal>, a left parenthesis, zero or more
1802 expressions (separated by commas) for the row field values, and finally
1803 a right parenthesis. For example:
1805 SELECT ROW(1,2.5,'this is a test');
1807 The key word <literal>ROW</> is optional when there is more than one
1808 expression in the list.
1812 A row constructor can include the syntax
1813 <replaceable>rowvalue</replaceable><literal>.*</literal>,
1814 which will be expanded to a list of the elements of the row value,
1815 just as occurs when the <literal>.*</> syntax is used at the top level
1816 of a <command>SELECT</> list. For example, if table <literal>t</> has
1817 columns <literal>f1</> and <literal>f2</>, these are the same:
1819 SELECT ROW(t.*, 42) FROM t;
1820 SELECT ROW(t.f1, t.f2, 42) FROM t;
1826 Before <productname>PostgreSQL</productname> 8.2, the
1827 <literal>.*</literal> syntax was not expanded, so that writing
1828 <literal>ROW(t.*, 42)</> created a two-field row whose first field
1829 was another row value. The new behavior is usually more useful.
1830 If you need the old behavior of nested row values, write the inner
1831 row value without <literal>.*</literal>, for instance
1832 <literal>ROW(t, 42)</>.
1837 By default, the value created by a <literal>ROW</> expression is of
1838 an anonymous record type. If necessary, it can be cast to a named
1839 composite type — either the row type of a table, or a composite type
1840 created with <command>CREATE TYPE AS</>. An explicit cast might be needed
1841 to avoid ambiguity. For example:
1843 CREATE TABLE mytable(f1 int, f2 float, f3 text);
1845 CREATE FUNCTION getf1(mytable) RETURNS int AS 'SELECT $1.f1' LANGUAGE SQL;
1847 -- No cast needed since only one getf1() exists
1848 SELECT getf1(ROW(1,2.5,'this is a test'));
1854 CREATE TYPE myrowtype AS (f1 int, f2 text, f3 numeric);
1856 CREATE FUNCTION getf1(myrowtype) RETURNS int AS 'SELECT $1.f1' LANGUAGE SQL;
1858 -- Now we need a cast to indicate which function to call:
1859 SELECT getf1(ROW(1,2.5,'this is a test'));
1860 ERROR: function getf1(record) is not unique
1862 SELECT getf1(ROW(1,2.5,'this is a test')::mytable);
1868 SELECT getf1(CAST(ROW(11,'this is a test',2.5) AS myrowtype));
1877 Row constructors can be used to build composite values to be stored
1878 in a composite-type table column, or to be passed to a function that
1879 accepts a composite parameter. Also,
1880 it is possible to compare two row values or test a row with
1881 <literal>IS NULL</> or <literal>IS NOT NULL</>, for example:
1883 SELECT ROW(1,2.5,'this is a test') = ROW(1, 3, 'not the same');
1885 SELECT ROW(table.*) IS NULL FROM table; -- detect all-null rows
1887 For more detail see <xref linkend="functions-comparisons">.
1888 Row constructors can also be used in connection with subqueries,
1889 as discussed in <xref linkend="functions-subquery">.
1894 <sect2 id="syntax-express-eval">
1895 <title>Expression Evaluation Rules</title>
1898 <primary>expression</primary>
1899 <secondary>order of evaluation</secondary>
1903 The order of evaluation of subexpressions is not defined. In
1904 particular, the inputs of an operator or function are not necessarily
1905 evaluated left-to-right or in any other fixed order.
1909 Furthermore, if the result of an expression can be determined by
1910 evaluating only some parts of it, then other subexpressions
1911 might not be evaluated at all. For instance, if one wrote:
1913 SELECT true OR somefunc();
1915 then <literal>somefunc()</literal> would (probably) not be called
1916 at all. The same would be the case if one wrote:
1918 SELECT somefunc() OR true;
1920 Note that this is not the same as the left-to-right
1921 <quote>short-circuiting</quote> of Boolean operators that is found
1922 in some programming languages.
1926 As a consequence, it is unwise to use functions with side effects
1927 as part of complex expressions. It is particularly dangerous to
1928 rely on side effects or evaluation order in <literal>WHERE</> and <literal>HAVING</> clauses,
1929 since those clauses are extensively reprocessed as part of
1930 developing an execution plan. Boolean
1931 expressions (<literal>AND</>/<literal>OR</>/<literal>NOT</> combinations) in those clauses can be reorganized
1932 in any manner allowed by the laws of Boolean algebra.
1936 When it is essential to force evaluation order, a <literal>CASE</>
1937 construct (see <xref linkend="functions-conditional">) can be
1938 used. For example, this is an untrustworthy way of trying to
1939 avoid division by zero in a <literal>WHERE</> clause:
1941 SELECT ... WHERE x > 0 AND y/x > 1.5;
1945 SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;
1947 A <literal>CASE</> construct used in this fashion will defeat optimization
1948 attempts, so it should only be done when necessary. (In this particular
1949 example, it would be better to sidestep the problem by writing
1950 <literal>y > 1.5*x</> instead.)