[Moved to hackers}
On Sun, May 19, 2002 at 04:14:47PM -0400, Tom Lane wrote:
> meskes@postgresql.org (Michael Meskes) writes:
> > - Fixed reduce/reduce conflict in parser.
> > - Synced preproc.y with gram.y.
>
> Good, but now I get:
>
> $ make
> bison -y -d preproc.y
> preproc.y:5330: fatal error: maximum table size (32767) exceeded
> make: *** [preproc.h] Error 1
>
> This is with
>
> $ bison -V
> GNU Bison version 1.28
I'm using bison 1.35, but get the same error.
> Surprised the heck out of me --- I thought GNU tools weren't supposed
> to have arbitrary limits in them. Perhaps there's some error in the
> preproc.y file that's triggering this?
I wish it was. Here's what I found using google:
...
>"sqlparser.y", line 12054: maximum table size (32767) exceeded
>
> After doing some research, we found out that in the source code for
>bison v.1.25 there is a #define MAXTABLE 32767 in machine.h. We can
>modify that value, but does anyone now what would the consequences be?
I would look to see where the value is used, and be sure any tables
limited to that size are not addressed by short int's. The limit
probably reflects an assumed int size for the DOS target, making it
safe to change, but I would still check for short's.
>Is there another way to overcome this bison 32K limitation?
Push more of the work into the scanner? You must have one Hell of a
grammar.
...
It seems that there are only one or two projects ever to hit that limit.
But it appears to be a hardcoded limit inside bison. It seems I hit that
limit with the latest changes.
Right now I'm removing some simple rules to get under it again, but we
will certainly hit it again in the very near future.
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
