Robert Haas <robertmh...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
