Dear Tom,
> In particular you can't any longer tell the difference between BOOLEAN
> and "boolean" (with quotes), which are not the same thing --- a quoted
> string is never a keyword, per spec. [...]
Ok, so you mean that on -boolean- the lexer returns a BOOLEAN_P token, but
with -"boolean"- it
> >>(b) write a new "recursive descendant" parser, and drop "gram.y"
>
> er, that's "recursive descent" :-)
Sorry for my French version.
> Well, unless you are a serious masochist,
I'm not a masochist;-) I'm arguing about where hint should/could be put.
> In fact, considering this thread I'm n
Dear Tom,
> > I join a small proof-of-concept patch to drop some tokens out of the
> > parser.
>
> I believe these were treated this way *specifically* because of the
> keyword-is-not-an-identifier issue. SQL99 calls out most of these
> as being keywords:
Well, I think that the "reserved keywor
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> Another is that depending on where you put the renaming that this patch
>> removes without replacing :-(,
> I do not understand your point. It seems to me that the renaming is
> performed when a type name is expected? The "boolean" keyword (not token)
Dear Tom,
> No, just redefine "yyerror" as a macro that passes additional parameters.
Ok! That's just the kind of the hack-hook I was looking for!!
> > The terminals are not available, they must be kept separatly if you
> > want them. This can be done in yylex().
>
> We don't need them. Any a
Tom Lane wrote:
Fabien COELHO <[EMAIL PROTECTED]> writes:
(b) write a new "recursive descendant" parser, and drop "gram.y"
er, that's "recursive descent" :-)
Been there, done that, not impressed with the idea. There's a reason
why people invented parser generators...
Well, unless yo
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> If you can think of a reasonable way to stop treating them as separate
>> tokens inside the grammar without altering the user-visible behavior,
>> I'm certainly interested.
> I join a small proof-of-concept patch to drop some tokens out of the
> parser.
As another teaching aid idea, is there something that would auto-format
queries to they are more readable?
---
Fabien COELHO wrote:
>
>
>
> Dear Tom,
>
> > No, just redefine "yyerror" as a macro that passes additional pa
> As another teaching aid idea, is there something that would auto-format
> queries to they are more readable?
Not that I know of. But I guess it must exist in some interface,
maybe with Oracle or DB2.
My emacs does seem to do that. It just put colors on keywords.
If I had to put it somewhere,
Dear Tom,
> No, just redefine "yyerror" as a macro that passes additional parameters.
Ok! That's just the kind of the hack-hook I was looking for!!
> > The terminals are not available, they must be kept separatly if you
> > want them. This can be done in yylex().
>
> We don't need them. Any
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Although I agree that it is "doable", I have stronger reserve than yours.
> Also, I do not find it an appealing solution to change "gram.c" a lot.
I was not proposing hand-editing gram.c after bison generates it,
if that's what you meant ;-). It seems h
Dear Tom,
First, thanks for the discussion about my "hint" infrastructure patch
submission. Whatever the opinion, it helps.
> We'd have to write our own version of bison's verbose-error code anyway,
> because the canned code doesn't support localization --- it uses
> hardwired strings for "expe
Fabien COELHO <[EMAIL PROTECTED]> writes:
> That is done with YYERROR_VERBOSE, but the result is really poor
> most of the time, because it does not look for all possible terminals,
> just the ones easilly accessible.
I wasn't aware that bison had a built-in facility for better messages
--- this i
> > 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 suggesting was that we might be
Dear Tom,
> > Not really in terms of state. The state should basically be the same.
> > However yes in terms of "explicit" state that are given explicit names.
> > And definitely in terms of actions, as you say.
>
> But mid-rule actions are implemented by inventing additional internal
> productio
> I wonder if we could just do a \h command as a hint. In some cases, it
> might be clearer than printing some text.
\h SELECT or \h CREATE TABLE are 2 pages long.
For the beginner, it is a lot of help... a little bit too much.
So I think that a better job can be done. If I'm wrong, you don't
Dear Stephan,
> I can see them as potentially being useful for people who don't have alot
> of knowledge of SQL or our dialect thereof.
That is my audience.
> I think some of the ones shown may need better wording [...]
Sure. I'm not the man for writing very clear English sentences.
I may be m
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 b
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 a
On Fri, 2 Apr 2004, Bruce Momjian wrote:
> 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 us
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 NOCRE
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 w
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
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 loo
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
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 w
> 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 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 genera
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 <[EMAIL PROTECTED]> writes:
> I can resubmit a new patch that would provide the needed infrastructure
> AND some hints on some commands as a proof of concept of what can be
> achieved.
I quite agree that you shouldn't do a complete implementation when it's
not clear if we'll accept i
Dear Tom,
> > Well, the current status of the infrastructure is that there is no hint;-)
>
> Ah, now I remember why I was waiting to review that stuff: I was expecting
> you to come out with a version that actually did some things :-(
Well, if you wait for something from me, it is better to tell
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> Also, what is typical output for a hint? Can you show one?
> Well, the current status of the infrastructure is that there is no hint;-)
Ah, now I remember why I was waiting to review that stuff: I was expecting
you to come out with a version that actu
Dear Bruce,
> Why did all the tags have to be renamed:
>
> + cmdGRANT: GRANT {noH;};
that's a good question.
In order to add hints, I want to attach them to the states of the parser
automaton. So as to do that, I need I put a name on every state, so I need
to refactor the prefix that lead
Fabien COELHO wrote:
>
> Dear patchers,
>
> Well, as the discussion rages over my previous patch submissions, I've
> time to improve the code;-)
>
> I finally figured out that there is 2 errhint functions (elog.c vs
> ipc_text.c), and the one I'm calling is the fist one, so I need to put a
> for
Dear patchers,
Well, as the discussion rages over my previous patch submissions, I've
time to improve the code;-)
I finally figured out that there is 2 errhint functions (elog.c vs
ipc_text.c), and the one I'm calling is the fist one, so I need to put a
format. The second appears to ignore it's
35 matches
Mail list logo
