🌐 AI搜索 & 代理 主页
Skip to content

Commit a676386

Browse files
tglsfdctglsfdc
committed
Remove operator_precedence_warning.
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
1 parent 4f5760d commit a676386

File tree

10 files changed

+10
-535
lines changed

10 files changed

+10
-535
lines changed

‎doc/src/sgml/config.sgml‎

Lines changed: 0 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -9389,29 +9389,6 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
93899389
</listitem>
93909390
</varlistentry>
93919391

9392-
<varlistentry id="guc-operator-precedence-warning" xreflabel="operator_precedence_warning">
9393-
<term><varname>operator_precedence_warning</varname> (<type>boolean</type>)
9394-
<indexterm>
9395-
<primary><varname>operator_precedence_warning</varname> configuration parameter</primary>
9396-
</indexterm>
9397-
</term>
9398-
<listitem>
9399-
<para>
9400-
When on, the parser will emit a warning for any construct that might
9401-
have changed meanings since <productname>PostgreSQL</productname> 9.4 as a result
9402-
of changes in operator precedence. This is useful for auditing
9403-
applications to see if precedence changes have broken anything; but it
9404-
is not meant to be kept turned on in production, since it will warn
9405-
about some perfectly valid, standard-compliant SQL code.
9406-
The default is <literal>off</literal>.
9407-
</para>
9408-
9409-
<para>
9410-
See <xref linkend="sql-precedence"/> for more information.
9411-
</para>
9412-
</listitem>
9413-
</varlistentry>
9414-
94159392
<varlistentry id="guc-quote-all-identifiers" xreflabel="quote-all-identifiers">
94169393
<term><varname>quote_all_identifiers</varname> (<type>boolean</type>)
94179394
<indexterm>

‎doc/src/sgml/syntax.sgml‎

Lines changed: 1 addition & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1121,11 +1121,7 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
11211121
cases, these changes will result in no behavioral change, or perhaps
11221122
in <quote>no such operator</quote> failures which can be resolved by adding
11231123
parentheses. However there are corner cases in which a query might
1124-
change behavior without any parsing error being reported. If you are
1125-
concerned about whether these changes have silently broken something,
1126-
you can test your application with the configuration
1127-
parameter <xref linkend="guc-operator-precedence-warning"/> turned on
1128-
to see if any warnings are logged.
1124+
change behavior without any parsing error being reported.
11291125
</para>
11301126
</note>
11311127
</sect2>

‎src/backend/nodes/outfuncs.c‎

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3264,9 +3264,6 @@ _outAExpr(StringInfo str, const A_Expr *node)
32643264
appendStringInfoString(str, " NOT_BETWEEN_SYM ");
32653265
WRITE_NODE_FIELD(name);
32663266
break;
3267-
case AEXPR_PAREN:
3268-
appendStringInfoString(str, " PAREN");
3269-
break;
32703267
default:
32713268
appendStringInfoString(str, " ??");
32723269
break;

‎src/backend/parser/gram.y‎

Lines changed: 4 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -59,7 +59,6 @@
5959
#include "nodes/nodeFuncs.h"
6060
#include "parser/gramparse.h"
6161
#include "parser/parser.h"
62-
#include "parser/parse_expr.h"
6362
#include "storage/lmgr.h"
6463
#include "utils/date.h"
6564
#include "utils/datetime.h"
@@ -13461,28 +13460,6 @@ c_expr: columnref { $$ = $1; }
1346113460
n->indirection = check_indirection($4, yyscanner);
1346213461
$$ = (Node *)n;
1346313462
}
13464-
else if (operator_precedence_warning)
13465-
{
13466-
/*
13467-
* If precedence warnings are enabled, insert
13468-
* AEXPR_PAREN nodes wrapping all explicitly
13469-
* parenthesized subexpressions; this prevents bogus
13470-
* warnings from being issued when the ordering has
13471-
* been forced by parentheses. Take care that an
13472-
* AEXPR_PAREN node has the same exprLocation as its
13473-
* child, so as not to cause surprising changes in
13474-
* error cursor positioning.
13475-
*
13476-
* In principle we should not be relying on a GUC to
13477-
* decide whether to insert AEXPR_PAREN nodes.
13478-
* However, since they have no effect except to
13479-
* suppress warnings, it's probably safe enough; and
13480-
* we'd just as soon not waste cycles on dummy parse
13481-
* nodes if we don't have to.
13482-
*/
13483-
$$ = (Node *) makeA_Expr(AEXPR_PAREN, NIL, $2, NULL,
13484-
exprLocation($2));
13485-
}
1348613463
else
1348713464
$$ = $2;
1348813465
}
@@ -16516,16 +16493,10 @@ doNegateFloat(Value *v)
1651616493
static Node *
1651716494
makeAndExpr(Node *lexpr, Node *rexpr, int location)
1651816495
{
16519-
Node *lexp = lexpr;
16520-
16521-
/* Look through AEXPR_PAREN nodes so they don't affect flattening */
16522-
while (IsA(lexp, A_Expr) &&
16523-
((A_Expr *) lexp)->kind == AEXPR_PAREN)
16524-
lexp = ((A_Expr *) lexp)->lexpr;
1652516496
/* Flatten "a AND b AND c ..." to a single BoolExpr on sight */
16526-
if (IsA(lexp, BoolExpr))
16497+
if (IsA(lexpr, BoolExpr))
1652716498
{
16528-
BoolExpr *blexpr = (BoolExpr *) lexp;
16499+
BoolExpr *blexpr = (BoolExpr *) lexpr;
1652916500

1653016501
if (blexpr->boolop == AND_EXPR)
1653116502
{
@@ -16539,16 +16510,10 @@ makeAndExpr(Node *lexpr, Node *rexpr, int location)
1653916510
static Node *
1654016511
makeOrExpr(Node *lexpr, Node *rexpr, int location)
1654116512
{
16542-
Node *lexp = lexpr;
16543-
16544-
/* Look through AEXPR_PAREN nodes so they don't affect flattening */
16545-
while (IsA(lexp, A_Expr) &&
16546-
((A_Expr *) lexp)->kind == AEXPR_PAREN)
16547-
lexp = ((A_Expr *) lexp)->lexpr;
1654816513
/* Flatten "a OR b OR c ..." to a single BoolExpr on sight */
16549-
if (IsA(lexp, BoolExpr))
16514+
if (IsA(lexpr, BoolExpr))
1655016515
{
16551-
BoolExpr *blexpr = (BoolExpr *) lexp;
16516+
BoolExpr *blexpr = (BoolExpr *) lexpr;
1655216517

1655316518
if (blexpr->boolop == OR_EXPR)
1655416519
{

0 commit comments

Comments
 (0)