Re: Tablespace issues (comment on ,moving indexes)

Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > ...  But what we're talking about
> > here is brand new functionality for which the language hasn't been
> > defined yet.
> 
> You're missing the point, which is that there *is* a precedent of long
> standing.  ALTER TABLE has worked on indexes (and sequences, and views)
> for those cases in which the operation sensibly applied for a long time.
> In particular, the original 7.1 implementation of ALTER TABLE OWNER
> would work on tables, indexes, sequences, and views.  Should we really
> have insisted on inventing four syntaxes for the identical operation?
> Maybe, but we didn't, and now there is a precedent to follow.

And yet we have ALTER SEQUENCE.  In 7.4, we seem to have:

ALTER AGGREGATE
ALTER CONVERSION
ALTER DATABASE
ALTER DOMAIN
ALTER FUNCTION
ALTER GROUP
ALTER LANGUAGE
ALTER OPERATOR CLASS
ALTER SCHEMA
ALTER SEQUENCE
ALTER TABLE
ALTER TRIGGER
ALTER USER


Within ALTER TABLE, you can change:

1. columns
2. the table name
3. constraints
4. table ownership
5. index clustering

and within those, only (2) and (4) apply to sequences and views, and (5)
is the only ALTER TABLE operation that applies to indexes (corrections
to this welcome).  Furthermore, the rename operation for triggers,
languages, groups, functions, databases, conversions, and aggregates are
all implemented in their own ALTER statement (indeed, the rename
operation is the only ALTER operation for some of those).

The decision to roll some of the functionality affecting sequences and
views into ALTER TABLE is at least somewhat sensible: those things look
like tables in at least one key way, namely that they can be SELECTed
from.  That's not true of indexes, and so that reasoning does not apply
to using ALTER TABLE to change an index's tablespace.


It appears to me that the precedent for creating a new ALTER statement
is actually much bigger than the precedent for rolling functionality
into ALTER TABLE, based on the above.



But that's just my bird's eye view on things.  I'm sure lots of people
disagree with me on this.  :-)


I'm certainly not arguing for a wholesale rework of the syntax in order
to achieve maximum consistency (nice as that might be), but it seems to
me that it would be a mistake to introduce more inconsistency than is
already there when it's not necessary to do so.



-- 
Kevin Brown                          kevin@sysexperts.com