Christopher Kings-Lynne wrote:
> >Hmm...not ALTER INDEX? Now that there's an operation that actually
> >modifies an index instead of the table itself, should there be an ALTER
> >INDEX? It would be cleaner and more consistent, IMO...
>
> Errr, unlike all the other uses for alter table and friends? ie:
>
> OWNER TO
Which changes the attributes of the table...
> RENAME TO
Same.
> SET TABLESPACE
Which again changes the attributes of the table..
But using ALTER TABLE to change the tablespace that an index belongs to
doesn't change an attribute of a table, it changes the attribute of an
index.
> etc.
>
> Lots of things against tables work against indexes and views. Some
> stuff for commenting on columns say works on views, composite types and
> indexes!
No doubt. Of course, that something's been done a certain way in the
past doesn't imply that it's the right way to do something new, nor does
it imply that the new thing must be done that way.
I mean, it's not a terribly big deal or anything, but since we're talking
about stuff that isn't in the SQL spec it seems reasonable to define the
commands in such a way that they don't violate the principle of least
surprise. Using ALTER TABLE to alter the characteristics of an index
violates that principle, at least in my opinion. It's not the first
command I would have thought of when asking myself "how do I change the
tablespace of an index?" -- ALTER INDEX is. And the reason is simple:
we use CREATE INDEX to create an index and DROP INDEX to drop one -- we
don't use ALTER TABLE subcommands to create or drop indexes. Why, then,
should modification of an index's properties be treated any differently
than the rest of the index manipulation commands?
I just happen to like consistency. :-)
--
Kevin Brown kevin@sysexperts.com