From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: new keywords in 9.1 |
Date: | 2011-03-12 06:36:48 |
Message-ID: | 11079.1299911808@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> It looks like 9.1 currently introduces 11 new keywords: ATTRIBUTE,
> COLLATION, EXTENSION, LABEL, NOREPLICATION, PASSING, REF, REPLICATION,
> UNLOGGED, VALIDATE, and XMLEXISTS. Aside from VALIDATE, which is
> already being discussed on another thread, are there any of these that
> we can/should try to get rid of? At a quick glance, it looks quite
> simple to avoid making REPLICATION/NOREPLICATION into keywords, and we
> can actually *remove* a bunch of existing keywords using the same
> trick. Patch attached.
One trouble with this trick is that it cannot distinguish between, eg,
SUPERUSER and "superuser" (with the quotes), whereas the latter really
ought not act like a keyword. I'm not sure this is a big enough problem
to justify bloating the parser with extra keywords, though.
> It would be possible to make CREATE UNLOGGED TABLE work without making
> UNLOGGED a keyword using a similar trick, though it's a bit messy.
> SELECT .. INTO UNLOGGED foo can't work unless it's a keyword, though,
> I think, though I wouldn't cry much if we lost that option. I'm
> inclined to think this is not worth messing with more on grounds of
> ugliness than anything else.
-1 for changing that; I think that anything that is used in more than a
very circumscribed context is likely to come back to bite us if we play
cute-looking parser tricks.
A minor stylistic gripe:
> + if (!strcmp($1, "superuser"))
Please spell that as
+ if (strcmp($1, "superuser") == 0)
which is the house style around here. (I have a rant on file in the
archives about exactly why to do that, if you care, but the gist is that
the former way looks like a not-match rather than a match test.)
One other thought about this code is that you could possibly avoid
having gram.y bother with knowledge of the specific keywords at all:
just fling any IDENT into a makeDefElem and let dbcommands.c sort it
out. The syntax error messages might get a bit worse (no error pointer,
in particular) but how much do we care?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-12 08:53:11 | Re: template0 database comment |
Previous Message | Bruce Momjian | 2011-03-12 05:56:44 | Re: pg_dump -X |