Dear Tom,
> I quite agree that you shouldn't do a complete implementation when it's
> not clear if we'll accept it or not. What I'd like to see is a demo,
> basically. How about one example of each of several different kinds
> of hints? We need to get a feeling for what can be accomplished and how
> messy the grammar would get.
I've already tried some implementation but it was not showable, and
because the infrastructure was not in place, inappropriate hints could
be shown.
It is not "that" messy. Just prefix are given a name to attach a rule
for hint updates.
> BTW, it seems like you are putting in a lot of infrastructure to
> recreate externally the parse-stack state that bison has internally.
Yes.
> Maybe an interesting alternative would be to look at touching that
> state directly. I realize that bison doesn't consider that part of
> their official API, but bison is a stable tool and seems unlikely to
> change much in the future. We could probably get away with it...
Interesting, however:
I would not like to break postgresql portability with other parser
generators. It would be enough to reject the patch from my point of
view;-)
Using some non standard undocumented API would not help other people who
would like to touch the parser.
It would not help me either, because I would have to learn the
undocumented API;-)
I really need to give a name to the state so as to be able to attach a
hint. I cannot set how I could guess the state number given after "GRANT"
just from the source, and without generating lots of conflicts.
So I'll do some more programming maybe over the week-end a resubmit
something soon.
--
Fabien.
