Re: Updatable views/with check option parsing

Tom Lane said:
> Peter Eisentraut <peter_e(at)gmx(dot)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