database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Remove operator_precedence_warning.

Browse Source 
This GUC was always intended as a temporary solution to help with
finding 9.4-to-9.5 migration issues.  Now that all pre-9.5 branches
are out of support, and 9.5 will be too before v14 is released,
it seems like it's okay to drop it.  Doing so allows removal of
several hundred lines of poorly-tested code in parse_expr.c,
which have been a fertile source of bugs when people did use this.

Discussion: https://postgr.es/m/2234320.1607117945@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2020-12-08 16:29:52 -05:00
parent 4f5760d4af
commit a676386b58
10 changed files with 10 additions and 535 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
doc/src/sgml/config.sgml
View File

@ -9389,29 +9389,6 @@ 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</varname> 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</productname> 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</literal>.
</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>

6
doc/src/sgml/syntax.sgml
View File

@ -1121,11 +1121,7 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
cases, these changes will result in no behavioral change, or perhaps
in <quote>no such operator</quote> 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.
change behavior without any parsing error being reported.
</para>
</note>
</sect2>