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 по дате отправления: