Re: Parser Cruft in gram.y - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parser Cruft in gram.y
Date
Msg-id 24701.1355590369@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parser Cruft in gram.y  ("Kevin Grittner" <kgrittn@mail.com>)
Responses Re: Parser Cruft in gram.y
List pgsql-hackers
"Kevin Grittner" <kgrittn@mail.com> writes:
> Tom Lane wrote:
>> the parser tables are basically number-of-tokens wide by
>> number-of-states high. (In HEAD there are 433 tokens known to the
>> grammar, all but 30 of which are keywords, and 4367 states.)
>> 
>> Splitting the grammar into multiple grammars is unlikely to do
>> much to improve this --- in fact, it could easily make matters
>> worse due to duplication.

> Of course if they were both at 80% it would be a higher total than
> combined, but unless you have a handle on the percentages, it
> doesn't seem like a foregone conclusion. Do you have any feel for
> what the split would be?

I don't really, but I will note that the scalar-expression subgrammar is
a pretty sizable part of the whole, and it's difficult to see how you'd
make a useful split that didn't duplicate it.  I guess you could push
CREATE TABLE, ALTER TABLE, CREATE DOMAIN, ALTER DOMAIN, COPY, and
anything else that included expression arguments over into the "main"
grammar.  But that path leads to more and more stuff getting moved to
the "main" grammar over time, making the whole thing more and more
questionable.  The whole concept seems ugly and unmaintainable in any
case.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Set visibility map bit after HOT prune
Next
From: Tom Lane
Date:
Subject: Re: is allow_nonpic_in_shlib still useful?