mirror of
https://github.com/postgres/postgres.git
synced 2025-08-19 23:22:23 +03:00
Avoid recursion when processing simple lists of AND'ed or OR'ed clauses.
Since most of the system thinks AND and OR are N-argument expressions anyway, let's have the grammar generate a representation of that form when dealing with input like "x AND y AND z AND ...", rather than generating a deeply-nested binary tree that just has to be flattened later by the planner. This avoids stack overflow in parse analysis when dealing with queries having more than a few thousand such clauses; and in any case it removes some rather unsightly inconsistencies, since some parts of parse analysis were generating N-argument ANDs/ORs already. It's still possible to get a stack overflow with weirdly parenthesized input, such as "x AND (y AND (z AND ( ... )))", but such cases are not mainstream usage. The maximum depth of parenthesization is already limited by Bison's stack in such cases, anyway, so that the limit is probably fairly platform-independent. Patch originally by Gurjeet Singh, heavily revised by me
This commit is contained in:
@@ -458,12 +458,8 @@ typedef struct ScalarArrayOpExpr
|
||||
* BoolExpr - expression node for the basic Boolean operators AND, OR, NOT
|
||||
*
|
||||
* Notice the arguments are given as a List. For NOT, of course the list
|
||||
* must always have exactly one element. For AND and OR, the executor can
|
||||
* handle any number of arguments. The parser generally treats AND and OR
|
||||
* as binary and so it typically only produces two-element lists, but the
|
||||
* optimizer will flatten trees of AND and OR nodes to produce longer lists
|
||||
* when possible. There are also a few special cases where more arguments
|
||||
* can appear before optimization.
|
||||
* must always have exactly one element. For AND and OR, there can be two
|
||||
* or more arguments.
|
||||
*/
|
||||
typedef enum BoolExprType
|
||||
{
|
||||
|
Reference in New Issue
Block a user