Re: Parser Cruft in gram.y

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parser Cruft in gram.y
Дата
Msg-id 24701.1355590369@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parser Cruft in gram.y  ("Kevin Grittner" <kgrittn@mail.com>)
Ответы Re: Parser Cruft in gram.y
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Set visibility map bit after HOT prune
Следующее
От: Tom Lane
Дата:
Сообщение: Re: is allow_nonpic_in_shlib still useful?