Re: creating index names automatically?

On Fri, Dec 25, 2009 at 4:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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 particular case of EXPLAIN was discussed previously. Although I
think we have other ways to work around the problems discussed on that
thread, I came away from that discussion with the impression that you
were categorically opposed to adding any more non-standard reserved
words. Evidently that's not the case.

> 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)".

That's a valid concern. I admitted it was gross right from the start
- I just thought it might be better than having a non-standard
reserved word, especially for such a minor feature. If it isn't, it
isn't.

>> 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.

I wasn't intending to engage in pointless bellyaching. What I was
trying to do was point out that there are some common problems in all
of these cases, and trying to extract a design principle. I'm not
really sure why CREATE INDEX [CONCURRENTLY] is any different from
VACUUM [FULL] [FREEZE] [ANALYZE]. In both cases, the command and its
modifiers are immediately followed by a name, without any intervening
keyword or punctuation. In retrospect, that doesn't seem like a good
choice, at least to me, so, it might be something to look out for in
the future. YMMV, of course.

...Robert