Re: managing primary key conflicts while restoring data to table withexisting data - Mailing list pgsql-general

From Krishnakant Mane
Subject Re: managing primary key conflicts while restoring data to table withexisting data
Date
Msg-id bc684b8e-e84e-79e4-4a89-d616530bb40a@riseup.net
Whole thread Raw
In response to Re: managing primary key conflicts while restoring data to table with existing data  (Rob Sargent <robjsargent@gmail.com>)
List pgsql-general


On 25/09/19 4:32 PM, Rob Sargent wrote:


On Sep 25, 2019, at 1:15 AM, Krishnakant Mane <kkmane@riseup.net> wrote:

Hello all,

I have been using postgresql for an enterprise quality account's automation and inventory management software called GNUKhata <https://gnukhata.in>

Our team is planning to add backup and restore function in the software.

But we don't want to dump the entire database and then restore the same.

What we are trying to do is to copy data specific to an organization.

The challenge here is that I might copy all data (account heads, bills, vouchers etc ) for one organization from an instance on one machine.

I take the archive in what ever format to another machine and now attempt to restore.

The risk here is for example if the primary key value for orgcode in the organization table is 5, it might conflict with the data where I am attempting it to be restored.

Same holds true for bills, invoices etc.

A certain account head with accountcode 1 might be already present on the second machine.

I am not expecting the users to empty all data from the destination machine before restoring a backup.

The reason is that an auditor may have many client's data and one can't predict what primary key values are going to come from a backup.

Basically I can even say this is a copy paste instead of a pure backup and restore.

Can any one suggest how to handle such conflicts?


--
Regards,
Krishnakant Mane,
Project Founder and Leader,
GNUKhata
(Opensource Accounting, Billing and Inventory Management Software)
I’m not sure I like your definition of ‘backup and restore’ but you might get away with your approach if your keys were UUIDs. But I’ll bet dollars to doughnuts you’re using serial keys. Those seem to appeal to accounting types. 
--
Regards,
Hi Rob,
yes you are right, they are serial keys because timestamp or anything thereoff is agressively despised by the accountants and the likes.
Now I am really stuck as to what could be done.Krishnakant Mane,
Project Founder and Leader,
GNUKhata
(Opensource Accounting, Billing and Inventory Management Software)

pgsql-general by date:

Previous
From: Rob Sargent
Date:
Subject: Re: managing primary key conflicts while restoring data to table with existing data
Next
From: PegoraroF10
Date:
Subject: Re: Operator is not unique