Re: Call for objections: revision of keyword classification

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Call for objections: revision of keyword classification
Date: 2001-11-09 17:04:12
Message-ID: 20609.1005325452@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
>> Thinking about that, it seems like it might be nice to have a master
>> keyword file that contains just keywords and classifications:

> istm that we would have a better time using gram.y as the definitive
> source for this list.

That's what we're doing now, more or less, and it's got glaring
deficiencies. It's nearly unintelligible (cf Bruce's complaint
earlier in this thread) and it's horribly prone to human error.
Here are just three depressingly-easy-to-make mistakes against
which we have no mechanical check:

* keyword production mismatches token and action, eg

| FOO { $$ = "bar"; }

* failure to add new keyword to any of the appropriate lists;

* messing up the perfect sort order required in keyword.c.

What's worse is that the consequences of these mistakes are relatively
subtle and could escape detection for awhile. I'd like to see mistakes
of this kind become procedurally impossible.

> We could have a perl script (haven't looked; maybe Peter's utility
> already does this?) which rummages through gram.y and generates
> keyword.c.

I believe Peter's already doing some form of this, but gram.y is a
forbiddingly unfriendly form of storage for this information. It'd
be a lot easier and less mistake-prone to start from a *designed*
keyword database and generate the appropriate lists in gram.y.

BTW, another thing in the back of my mind is that we should try to
figure out some way to unify ecpg's SQL grammar with the backend's.
Maintaining that thing is an even bigger headache than getting the
backend's own parser right.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2001-11-09 17:06:17 Re: Possible major bug in PlPython (plus some other ideas)
Previous Message Kevin Jacobs 2001-11-09 16:32:44 Re: Possible major bug in PlPython (plus some other ideas)

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2001-11-09 17:09:22 Re: Patch for Makefile race against current cvs
Previous Message Greg Sabino Mullane 2001-11-09 14:53:17 Re: Enhanced index details using \d in psql