Re: Updatable views/with check option parsing

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Updatable views/with check option parsing
Дата
Msg-id 1852.24.211.165.134.1148684551.squirrel@www.dunslane.net
обсуждение исходный текст
Ответ на Re: Updatable views/with check option parsing  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Updatable views/with check option parsing
Список pgsql-hackers
Tom Lane said:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Andrew Dunstan wrote:
>>> "The GLR parsers require a compiler for ISO C89 or later. In
>>> addition, they use the inline keyword, which is not C89, but is C99
>>> and is a common extension in pre-C99 compilers. It is up to the user
>>> of these parsers to handle portability issues."
>
>> We already use inline, or handle its nonexistence, respectively.
>
> Yeah, I don't see anything in that statement that we don't assume
> already.  The interesting question to me is how much different is
> GLR from garden-variety bison; in particular, what's the parser
> performance like?
>

As I understand it, it runs one parser pretty much like the standard LALR(1)
case, until it finds an ambiguity (shift/reduce or reduce/reduce) at which
stage it clones the parser to take parallel paths, working in lockstep, and
storing up semantic actions. When one of the clones encounters an error it
goes away, and the surviving clone takes its stored semantic actions. If
that's true, then probably the only significant performance hit is in cases
of ambiguity, and we would only have a handful of those, each lasting for
one token, so the performance hit should be very small. We'd have to test
it, of course ;-)

cheers

andrew





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: max(*)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Updatable views/with check option parsing