"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I don't disagree with the premise that such hard-coded limits are
> undesirable but they also aren't always worth getting rid of, especially if
> they are inherited from an upstream dependency.
Having said all that ... I think there is a case here for raising
the core parser's YYMAXDEPTH, which would be a trivial matter of
inserting a #define for it. Bison's default value of 10000
was probably set decades ago for much smaller hardware. If I'm
computing it right, the space consumed per stack entry in PG
is 22 bytes (on 64-bit hardware), so that that limit corresponds
to only 220KB in stack, a fairly negligible number. We could
make it 10 or 100 times larger without anyone noticing ---
especially since this is the upper limit for resizing the stack,
not the amount of space used to parse simple inputs. That would
get us to a point where expression complexity would almost always
be limited by max_stack_depth, which the user has control over.
In theory we could make the limit as high as around 45M stack
levels, which would approach palloc's 1GB chunk limit. But
I can't foresee a reason to let the parser stack get anywhere near
that big. If you wrote millions of unmatched left parentheses,
you're just trying to cause trouble. So I'd vote for going to
100K or 1M.
regards, tom lane
