Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

deparse.c

  • Tom Lane's avatar
    2146f134
    Avoid recursion when processing simple lists of AND'ed or OR'ed clauses. · 2146f134
    Tom Lane authored
    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
    2146f134
    History
    Avoid recursion when processing simple lists of AND'ed or OR'ed clauses.
    Tom Lane authored
    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