From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Andreas Joseph Krogh <andreas(at)visena(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Replacing an existing unique constraint (not UNIQUE INDEX) with primary key |
Date: | 2016-12-20 15:17:35 |
Message-ID: | bcb5da81-ef36-3c64-f1eb-50ca2887dd8b@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 12/20/2016 03:03 AM, Andreas Joseph Krogh wrote:
> På tirsdag 20. desember 2016 kl. 11:42:56, skrev Achilleas Mantzios
> <achill(at)matrix(dot)gatewaynet(dot)com <mailto:achill(at)matrix(dot)gatewaynet(dot)com>>:
>
> On 20/12/2016 12:27, Andreas Joseph Krogh wrote:
>> På tirsdag 20. desember 2016 kl. 11:02:27, skrev Achilleas
>> Mantzios <achill(at)matrix(dot)gatewaynet(dot)com
>> <mailto:achill(at)matrix(dot)gatewaynet(dot)com>>:
>>
>> On 20/12/2016 11:43, Andreas Joseph Krogh wrote:
>>> [snip]
>> BEGIN;
>> ALTER TABLE person ADD CONSTRAINT person_pk PRIMARY KEY
>> (entity_id);
>> alter table person drop constraint person_entity_id_key CASCADE;
>> alter table phone add CONSTRAINT phone_fk FOREIGN KEY
>> (person_entity_id) REFERENCES person(entity_id);
>> alter table address add CONSTRAINT address_fk FOREIGN KEY
>> (person_id) REFERENCES person(entity_id);
>> COMMIT;
>>
>>
>> Yea, I was hoping to avoid having to manually add the FK's to the
>> referencing tables (34).
>> Is there really no way to accomplish this without DROP CONSTRAINT
>> ... CASCADE, hacking the system-catalogs or something?
>>
> You may write a script to output those 34 FK constraints. Definitely
> safer than hacking pg_constraint.conindid
>
>
> Yes.
>
> I'd still argue that what I'm trying to do should "just work" as PG
> treats UNIQUE CONSTRAINT and UNIQUE INDEX the same wrt. the planner and
> FK-enforcement.
Close as I can come:
test=# ALTER TABLE person
ADD CONSTRAINT person_pkey PRIMARY KEY (entity_id);
ALTER TABLE
test=# \d person
Table "public.person"
Column | Type | Modifiers
-----------+-------------------+-----------
entity_id | bigint | not null
name | character varying | not null
Indexes:
"person_pkey" PRIMARY KEY, btree (entity_id)
"person_entity_id_key" UNIQUE CONSTRAINT, btree (entity_id)
Referenced by:
TABLE "address" CONSTRAINT "address_person_id_fkey" FOREIGN KEY
(person_id) REFERENCES person(entity_id)
TABLE "phone" CONSTRAINT "phone_person_entity_id_fkey" FOREIGN KEY
(person_entity_id) REFERENCES person(entity_id)
Though you cannot DROP the original constraint index until you change
what the FKs point to. It buys you time to do that though.
test=# ALTER TABLE person DROP CONSTRAINT person_entity_id_key;
ERROR: cannot drop constraint person_entity_id_key on table person
because other objects depend on it
DETAIL: constraint phone_person_entity_id_fkey on table phone depends
on index person_entity_id_key
constraint address_person_id_fkey on table address depends on index
person_entity_id_key
HINT: Use DROP ... CASCADE to drop the dependent objects too.
>
> --
> *Andreas Joseph Krogh*
> CTO / Partner - Visena AS
> Mobile: +47 909 56 963
> andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com>
> www.visena.com <https://www.visena.com>
> <https://www.visena.com>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Paolo Saudin | 2016-12-20 19:01:32 | Re: pgAdmin 4 - auto disconnect |
Previous Message | Andreas Joseph Krogh | 2016-12-20 11:03:14 | Re: Replacing an existing unique constraint (not UNIQUE INDEX) with primary key |