Re: new keywords in 9.1

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

In response to

Responses

Browse pgsql-hackers by date

  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