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
Fabien COELHO wrote:
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;-)
We require bison to build, period. I am sure we use enough
bison-specific stuff now. No one has suggested another parser
Please show us an example of what a typical hint would look like to the
user.
As an illustration, here is the kind of thing I had with an early
quick and dirty proof of concept implementation I made for myself
one month ago.
As a result of this first try, I've convinced myself that I should
Fabien COELHO [EMAIL PROTECTED] writes:
I would not like to break postgresql portability with other parser
generators.
I agree with Bruce's opinion that this is a nonissue. In particular I'd
point out that the current grammar is already too big for any known yacc
clone besides bison (even with
Dear Tom,
I would not like to break postgresql portability with other parser
generators.
I agree with Bruce's opinion that this is a nonissue. In particular I'd
point out that the current grammar is already too big for any known yacc
clone besides bison (even with bison you need a very
Fabien COELHO wrote:
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
anyway.
Yes.
I don't know whether bison's internal tables expose that set in any
useful fashion, but it surely seems worth a
Fabien COELHO [EMAIL PROTECTED] writes:
... your proposed changes are going to make the grammar a whole lot
larger yet, at least in terms of states and actions.
Not really in terms of state. The state should basically be the same.
However yes in terms of explicit state that are given explicit
Andrew Dunstan [EMAIL PROTECTED] writes:
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!
What I was
Fabien COELHO wrote:
CREATE USER calvin WITH IN GROUP admin, CREATEDB;
ERROR: group admin does not exist
CREATE USER calvin WITH IN GROUP admin CREATEDB foo;
ERROR: syntax error at or near foo at character 49
HINT: other user options or ';' expected
CREATE USER calvin NOCREATEUSER
Stephan Szabo wrote:
I hate to say it but I don't see these hints as being very helpful.
I can see them as potentially being useful for people who don't have alot
of knowledge of SQL or our dialect thereof. I think some of the ones
shown may need better wording (for example the ones above
Stephan Szabo [EMAIL PROTECTED] writes:
I'm not sure that the HINT strings would be as meaningful in the middle of
complicated select/update/etc queries, but that would be something to see.
That's pretty much my stumbling block too. The examples Fabien has
shown so far don't seem to me to be
11 matches
Mail list logo
