Robert Haas <robertmh...@gmail.com> writes:
> Having said all this, I don't really object to the alternate proposal
> of creating a set of words that are reserved as relation names but not
> as column names, either, especially if it would allow us to make some
> other existing keywords less-reserved. But I don't really understand
> the justification for thinking that CONCURRENTLY is OK to make more
> reserved, but, say, EXPLAIN would not be OK.
You're attacking a straw man --- no such comparison was made or
implied. In practice, if we were up against a situation where we seemed
to need to make EXPLAIN more reserved, we'd consider that and the
alternatives on their own merits, not by reference to whether it should
be more reserved than CONCURRENTLY. IMO these are always going to be
one-of-a-kind decisions; I feel no desire to propose a hard and fast
rule about them.
The basic problem I've got with kluges such as you proposed is that it's
impossible to explain them to users. "CONCURRENTLY is unreserved,
except that in the context of a CREATE INDEX target it'll be interpreted
as an option not an index name"? Ugh. If we make a separate keyword
category for it, at least we can document that in a reasonably
straightforward fashion: "unreserved (cannot be table name)".
> I think what we should learn from this case, as well as the recent
> changes to EXPLAIN, COPY, and VACUUM syntax, is that adding options to
> commands by creating keywords is not very scalable, and that putting
> the modifier immediately after the command name is an especially poor
> positioning.
Perhaps. The original VACUUM syntax is a pretty bad piece of design,
dating from a time when we didn't even have a clear notion of which
keywords were reserved and which weren't; if it were proposed today
I'm confident we'd notice the problem and reject the syntax. It's less
obvious that CREATE INDEX CONCURRENTLY was a bad idea. We did consider
alternative syntaxes and rejected them on (IIRC) the grounds that they
didn't read well. Even now, the only thing you can really say against
it is that it got in the way of making the index name optional, but
every syntax choice forecloses some other choices. Complaining because
we didn't have the 20-20 foresight needed to realize that we'd want to
make the index name optional later on isn't very useful.
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
