Re: Parser Cruft in gram.y

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <kgrittn(at)mail(dot)com>
Cc: "Dimitri Fontaine" <dimitri(at)2ndQuadrant(dot)fr>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parser Cruft in gram.y
Date: 2012-12-15 16:52:49
Message-ID: 24701.1355590369@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <kgrittn(at)mail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-15 17:07:22 Re: is allow_nonpic_in_shlib still useful?
Previous Message Simon Riggs 2012-12-15 16:45:36 Re: Set visibility map bit after HOT prune