Search Postgresql Archives

Re: managing primary key conflicts while restoring data to table with existing data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--
Regards,
Krishnakant Mane,
Project Founder and Leader,
GNUKhata
(Opensource Accounting, Billing and Inventory Management Software)
You might think about adding the new UUID column and use the existing primary key to inform the updates in dependent tables. Then remove the old PK  column and constraint followed by promoting the UUID to primary key. This could be safely scripted and applied to all instances of your data. 
That said, this is only truly necessary of you have production databases to worry about.


Thanks a million, this is the most logical and safe way.

yes I have a lot of production databases to worry about.

I am only confused about what you mean by "use the existing primary key to inform the updates in dependent tables."

Are you refering to a cascading effect?

If yes then does it mean I first program my upgrade script to manually go through all new uuid keys and update the same in the depending tables with reference to the old primary key working as foreign key in those tables?


It occurs to me you will also need to "duplicate" the columns in which you have foreign keys.  How many tables are there in the affected schemata and what is the size? Pretty sure you will have to go off-line to perform this sort of transition.  Nearly everything will be touched.

--
Regards,
Krishnakant Mane,
Project Founder and Leader,
GNUKhata
(Opensource Accounting, Billing and Inventory Management Software)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux