Hi Stephan, Sridhar,
> > OK. From last thread, there was one more bell of caution. Having
foreign
> key
> > constraints.
> >
> > What I would suggest you to do is as follows.
> >
> > beign
> >
> > create new table as select into..
> > create any necessary indexes on new table.
> > rename old table as something else.
> > rename new table as original table
> >
> > commit
> >
> > drop old table.
> >
> > It should take care of mos practical problems that I can think of,
right
> now.
>
> That won't copy foreign key constraints, unfortuntately. Foreign keys
> aren't to a name, they're to an object, so a constraint to the old
table
> is still to the old table no matter what you rename it to and if
something
> else is renamed to the the old table's old table.
Aha I didn't realize the significance of the transaction block in
Sridhar's previous email. In this case we should be ok since we're not
using inheritance or foreign key constraints - I was just thinking about
the more generic case when trying to come up with a better way to
vacuum. But it would have been an interesting hack if it had worked :)
Progress on clearing up the database is going well, we're getting real
close now....
Cheers,
Mark.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England
Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
