On fim, 2006-12-07 at 13:57 -0800, Jeff Davis wrote:
> On Thu, 2006-12-07 at 20:07 +0000, Ragnar wrote:
> > On fim, 2006-12-07 at 09:27 -0800, Jeff Davis wrote:
> > > On Thu, 2006-12-07 at 12:26 +0000, Ragnar wrote:
> > > > On mið, 2006-12-06 at 18:22 -0800, Jeff Davis wrote:
> > > >
> > > > > 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;
> > > > >
>
> You've got a valid use-case, but it's completely different from the one
> I suggested. I wanted to be able to build an index concurrently (with
> the new functionality in 8.2) and then switch the primary key to use
> that new index, and then drop the old index.
>
> The reason is because that allows a 0-downtime index rebuild on a
> primary key's index without losing it's primary key status.
my point was just that 'primary key' is really just
a property of a set of attributes, and it is just
incidental that postgres enforces this property
with an index.
so if if a ALTER TABLE SET PRIMARY KEY is implemented,
it should involve a set of attributes, but not an index.
in your use case, the ALTER should not really be needed.
lets say you have PRIMARY KEY (a,b) on some table.
you decide you want to rebuild the primary key concurrently. just build
a new index on (a,b).
if you then drop the old index, the primary key constraint can still be
enforced by the new index, so
the DROP should be allowed to proceed, without affecting
the constraint.
on the other hand, the PRIMARY KEY property is really
only there because the standards say so, but does not
have a great value in my opinion, so the ability to
alter it would not be high on my priority lists.
gnari
