The last time I studied this stuff (which was quite a while back) the
follow set was something an LR parser generator would have to compute
I don't know whether bison's internal tables expose that set in any
useful fashion, but it surely seems worth a look.
Having a look is something I can do;-)
I'm afraid it looks like "internal state 1232, 43425 and 42523", but there
may be some support enough in the generated code to get something more
interesting. It would require to be able to get textual meta informations
out of the state number, which is possible if bison/flex people did
something about it.
You *really* don't want to go there. If you want to see what the parser is doing you can run "bison -r all" over the grammar and examine the .output file. But please, let's not examine the internal states. Talk about unmaintainability! Also, I suspect that bison does a good bit of optimisation by way of combining states that removes some of the information you might need, but I haven't looked into it closely.
If we really wanted to go down this route, a predictive (i.e. LL(n) type) parser rather than a bottom up parser would probably be more suitable, but I doubt anyone has any stomach for doing that work, even if there was agreement on the need for it.
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match