pgsql/src/interfaces/ecpg ChangeLog preproc/ec ...

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

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?

regards, tom lane

[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!

Michael Meskes <meskes@postgresql.org> writes:

[Moved to hackers}
On Sun, May 19, 2002 at 04:14:47PM -0400, Tom Lane wrote:

preproc.y:5330: fatal error: maximum table size (32767) exceeded

This is with
$ bison -V
GNU Bison version 1.28

I'm using bison 1.35, but get the same error.

1.35? Sounds like bison development has become active again. It was
stuck at 1.28 for a *long* time.

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.

Yes. Maybe we should contact the Bison developers and lobby for an
increase in the standard value. I don't mind saying "you must use
Bison 1.36 or newer to rebuild the Postgres grammar" ... but having to
say "you must use a nonstandardly patched Bison" would really suck :-(

regards, tom lane

On Mon, May 20, 2002 at 10:31:57AM -0400, Tom Lane wrote:

Yes. Maybe we should contact the Bison developers and lobby for an
increase in the standard value. I don't mind saying "you must use
Bison 1.36 or newer to rebuild the Postgres grammar" ... but having to
say "you must use a nonstandardly patched Bison" would really suck :-(

I fully agree.

Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!