diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/config.sgml | 23 | ||||
| -rw-r--r-- | doc/src/sgml/syntax.sgml | 84 |
2 files changed, 63 insertions, 44 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 07214bfd76a..d0f43c64af3 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -6816,6 +6816,29 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir' </listitem> </varlistentry> + <varlistentry id="guc-operator-precedence-warning" xreflabel="operator_precedence_warning"> + <term><varname>operator_precedence_warning</varname> (<type>boolean</type>) + <indexterm> + <primary><varname>operator_precedence_warning</> configuration parameter</primary> + </indexterm> + </term> + <listitem> + <para> + When on, the parser will emit a warning for any construct that might + have changed meanings since <productname>PostgreSQL</> 9.4 as a result + of changes in operator precedence. This is useful for auditing + applications to see if precedence changes have broken anything; but it + is not meant to be kept turned on in production, since it will warn + about some perfectly valid, standard-compliant SQL code. + The default is <literal>off</>. + </para> + + <para> + See <xref linkend="sql-precedence"> for more information. + </para> + </listitem> + </varlistentry> + <varlistentry id="guc-quote-all-identifiers" xreflabel="quote-all-identifiers"> <term><varname>quote_all_identifiers</varname> (<type>boolean</type>) <indexterm> diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml index 8283e252582..ff2c3e2b9a3 100644 --- a/doc/src/sgml/syntax.sgml +++ b/doc/src/sgml/syntax.sgml @@ -984,10 +984,11 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) associativity of the operators in <productname>PostgreSQL</>. Most operators have the same precedence and are left-associative. The precedence and associativity of the operators is hard-wired - into the parser. This can lead to non-intuitive behavior; for - example the Boolean operators <literal><</> and - <literal>></> have a different precedence than the Boolean - operators <literal><=</> and <literal>>=</>. Also, you will + into the parser. + </para> + + <para> + You will sometimes need to add parentheses when using combinations of binary and unary operators. For instance: <programlisting> @@ -1008,7 +1009,7 @@ SELECT (5 !) - 6; </para> <table id="sql-precedence-table"> - <title>Operator Precedence (decreasing)</title> + <title>Operator Precedence (highest to lowest)</title> <tgroup cols="3"> <thead> @@ -1063,63 +1064,35 @@ SELECT (5 !) - 6; </row> <row> - <entry><token>IS</token></entry> - <entry></entry> - <entry><literal>IS TRUE</>, <literal>IS FALSE</>, <literal>IS NULL</>, etc</entry> - </row> - - <row> - <entry><token>ISNULL</token></entry> - <entry></entry> - <entry>test for null</entry> - </row> - - <row> - <entry><token>NOTNULL</token></entry> - <entry></entry> - <entry>test for not null</entry> - </row> - - <row> - <entry>(any other)</entry> + <entry>(any other operator)</entry> <entry>left</entry> <entry>all other native and user-defined operators</entry> </row> <row> - <entry><token>IN</token></entry> - <entry></entry> - <entry>set membership</entry> - </row> - - <row> - <entry><token>BETWEEN</token></entry> - <entry></entry> - <entry>range containment</entry> - </row> - - <row> <entry><token>OVERLAPS</token></entry> <entry></entry> <entry>time interval overlap</entry> </row> <row> - <entry><token>LIKE</token> <token>ILIKE</token> <token>SIMILAR</token></entry> + <entry><token>BETWEEN</token> <token>IN</token> <token>LIKE</token> <token>ILIKE</token> <token>SIMILAR</token></entry> <entry></entry> - <entry>string pattern matching</entry> + <entry>range containment, set membership, string matching</entry> </row> <row> - <entry><token><</token> <token>></token></entry> + <entry><token><</token> <token>></token> <token>=</token> <token><=</token> <token>>=</token> <token><></token> +</entry> <entry></entry> - <entry>less than, greater than</entry> + <entry>comparison operators</entry> </row> <row> - <entry><token>=</token></entry> - <entry>right</entry> - <entry>equality, assignment</entry> + <entry><token>IS</token> <token>ISNULL</token> <token>NOTNULL</token></entry> + <entry></entry> + <entry><literal>IS TRUE</>, <literal>IS FALSE</>, <literal>IS + NULL</>, <literal>IS DISTINCT FROM</>, etc</entry> </row> <row> @@ -1159,9 +1132,32 @@ SELECT (5 !) - 6; SELECT 3 OPERATOR(pg_catalog.+) 4; </programlisting> the <literal>OPERATOR</> construct is taken to have the default precedence - shown in <xref linkend="sql-precedence-table"> for <quote>any other</> operator. This is true no matter + shown in <xref linkend="sql-precedence-table"> for + <quote>any other operator</>. This is true no matter which specific operator appears inside <literal>OPERATOR()</>. </para> + + <note> + <para> + <productname>PostgreSQL</> versions before 9.5 used slightly different + operator precedence rules. In particular, <token><=</token> + <token>>=</token> and <token><></token> used to be treated as + generic operators; <literal>IS</> tests used to have higher priority; + and <literal>NOT BETWEEN</> and related constructs acted inconsistently, + being taken in some cases as having the precedence of <literal>NOT</> + rather than <literal>BETWEEN</>. These rules were changed for better + compliance with the SQL standard and to reduce confusion from + inconsistent treatment of logically equivalent constructs. In most + cases, these changes will result in no behavioral change, or perhaps + in <quote>no such operator</> failures which can be resolved by adding + parentheses. However there are corner cases in which a query might + change behavior without any parsing error being reported. If you are + concerned about whether these changes have silently broken something, + you can test your application with the configuration + parameter <xref linkend="guc-operator-precedence-warning"> turned on + to see if any warnings are logged. + </para> + </note> </sect2> </sect1> |