On mið, 2006-12-06 at 18:22 -0800, Jeff Davis wrote: > On Wed, 2006-12-06 at 15:00 -0500, Chris Browne wrote: > > Let me add another question to this; this might possibly be worthy of > > a TODO for 8.3 or so... > > > > What if I wanted to: > > ALTER TABLE distributors ADD PRIMARY KEY CONCURRENTLY (dist_id); > Interesting, I was just thinking about this today as well. I am thinking > it would be nice if we could: > > ALTER TABLE SET PRIMARY KEY INDEX foo_pkey; > > If it's already got a primary key we switch the primary key to be the > new primary key > > (throwing an error if the columns don't match up to the > existing primary key, not sure what you mean by this > or if it's not unique). must also be NOT NULL > If not, the primary key > attribute is added to the existing index and the columns in the index > now make up the primary key (throwing an error if the index is not > unique). What about existing foreign key constraints ? as the only function of the PRIMARY key property of an index is making it the default target of a foreign key reference, you would have to decide what implications this has. Possibly none, as I am not sure the foreign key constraint remembers if the target was a primary key or not. also, your proposed syntax muddies the relationship between the PRIMARY KEY constraint and the existence of an INDEX. There is no such relationship in the SQL standards. possibly more appropriate would be ALTER TABLE SET PRIMARY KEY (columns) and an error issued if no UNIQUE NOT NULL index is found on the relevant columns one other question is what shuld happen to the original index that was implicitly created. should it be dropped automatically ? gnari
