Have you tested your own proposal on a real database?
If you rename aliases to aliases_1 postgres still wont allow you to create aliases. That was the reason for this hack. But perhaps I misunderstand some underlying postgres mechanism, but this is how I solved it.
Hans Kristian Rosbach wrote:
Is there any reason for this code? -- required tables: CREATE TABLE aliases_1 AS SELECT * FROM aliases; CREATE TABLE users_1 AS SELECT * FROM users; CREATE TABLE mailboxes_1 AS SELECT * FROM mailboxes; CREATE TABLE messages_1 AS SELECT * FROM messages; CREATE TABLE messageblks_1 AS SELECT * FROM messageblks; DROP TABLE aliases; DROP TABLE messageblks; DROP TABLE messages; DROP TABLE mailboxes; DROP TABLE users; DROP TABLE pbsp; should it not be: -- rename tables: ALTER TABLE aliases RENAME TO aliases_1 ALTER TABLE users RENAME TO users_1 ALTER TABLE mailboxes RENAME TO mailboxes_1 ALTER TABLE messages RENAME TO messages_1 ALTER TABLE messageblks RENAME TO messageblks_1 No need to COPY the table contents, as that a: takes time (more downtime) b: takes double space (BAD if big databases) It should also be considered to add 'BEGIN TRANSACTION' to the top of the script and 'COMMIT' to the end. This would make the changes only commit if everything goes without a hitch. Advantage with transaction: -Less downtime -Less chance of a half-merged database with no way back Disadvantages: -Requires extra space I will commit these to the bugtracker. -HK _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
-- ________________________________________________________________ Paul Stevens mailto:[EMAIL PROTECTED] NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED] The Netherlands________________________________http://www.nfg.nl
