From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: hint infrastructure setup (v3) |
Date: | 2004-04-03 09:20:05 |
Message-ID: | Pine.LNX.4.58.0404031103210.1733@mordor.coelho.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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
> productions
Sure.
> That's not only more states, but more symbols, which is going to impose
> an O(N^2) cost on the raw tabular representation of the parsing rules.
> Maybe much of this will be bought back when bison compresses the tables,
> and maybe not.
Mmh. Maybe. I don't know at the time.
> Have you checked how much the size of gram.o grows with the stuff
> you've installed so far?
I have not looked at that. It was just a quick and dirty implementation,
just to convince myself of what can be achieved.
> (I'm also slightly worried about what this will do to parsing speed,
Well, more reductions are performed, and I'm not sure that the switch()
implementation is really intelligent. Having a hash table could help big
grammars, but that is bison problems, and I will not rewrite that.
However, I'm not sure that parsing overhead is a big issue wrt other costs
in the backend, but this is not a reason to make it explode.
> > I'm afraid it looks like "internal state 1232, 43425 and [...],
>
> The string names of the grammar symbols are all embedded in gram.c
Yes, I've noticed yytname[].
> anyway, so if you can figure out the symbols that are expected next,
> their names could be printed directly.
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. So you have something like:
DROP TABL foo;
ERROR: syntax error at unexpected Ident "TABL", LANGUAGE expected.
no comment. A better job could be done, but you need to "touch" a little
bit "gram.c" for that.
> We could alter the symbol names to be more useful to novices, or
> alternatively install an additional lookup table to substitute
> reader-friendly phrases.
Yep, I thought about that also. Some symbols are appended "_P" to avoid
clashes.
I'm investigating the "internal" way. Not really optimistic because
of the details, but I may find workarounds. I'll post later when I'll
have a definite opinion.
--
Fabien COELHO _ http://www.cri.ensmp.fr/~coelho _ Fabien(dot)Coelho(at)ensmp(dot)fr
CRI-ENSMP, 35, rue Saint-Honoré, 77305 Fontainebleau cedex, France
phone: (+33|0) 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08}
________ All opinions expressed here are mine _________
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2004-04-03 09:31:14 | Re: hint infrastructure setup (v3) |
Previous Message | Fabien COELHO | 2004-04-03 08:56:35 | Re: hint infrastructure setup (v3) |