On Fri, Jul 6, 2012 at 2:07 PM, rverghese <riyav@xxxxxxxxxxx> wrote:
Having to drop and create foriegn keys is a legitimate concern. I am looking into improving that.
If you look closely at that example, DROP and CREATE of the primary key is being done in one command (and hence one transaction), so anything that depends this constraint should not be affected except from the fact that this table will be locked in exclusive mode for the duration of this operation, which should be very short.
Best regards,
-- Yes I am using that option for one of my POstgres 9.1 database and it works
well. But its still an issue with Foreign keys, which you need to drop and
recreate .
Having to drop and create foriegn keys is a legitimate concern. I am looking into improving that.
Also I use Slony for replication and it uses the primary key to
check repl. So I don't want that to be interrupted by dropping PK and
recreating PK.
If you look closely at that example, DROP and CREATE of the primary key is being done in one command (and hence one transaction), so anything that depends this constraint should not be affected except from the fact that this table will be locked in exclusive mode for the duration of this operation, which should be very short.
Best regards,
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
