From: | Viktor Valy <vili0121(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "chris(dot)gut" <chris(dot)gut(at)gmx(dot)at> |
Subject: | TODO Alter Table Rename Constraint |
Date: | 2010-11-09 15:50:09 |
Message-ID: | AANLkTi=yFqezf1iUXKTjvoFPH-dMWAMec1JH1Q3CWy4X@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Everybody!
I looked up this todo, and figured out a plan, how the implementation could
be written.
The main challenge is to keep constraints and indexes (for unique and PK
constraints) consistent.
Fortunately this is already realized in the case of an index. So at ALTER
INDEX RENAME the consistency is given by an extra check in *tablecmds.c
(Line 2246)*, where a function is finally called,* RenameConstraintById
(pg_constraint.c Line 604)*.
My idea is, to do that analog for ALTER CONSTRAINT RENAME too. So renaming
the constraint is going to be done in *tablecmds.c* as for indexes, tables,
sequences, views. And after checking whether the renametype is constraint,
an extra rename has to be done for the index. Getting the index can be done
with the function *get_constraint_index (pg_depend.c Line 475)*. Now it
should be possible to do the same as in *RenameConstraintById.*
Is that so legal? Is anything else to be considered?
I appreciate any suggestion, and maybe some help too, as I'm not so familiar
with the source.
Thanks in advance,
Viktor
(Student of technical unverstity of Vienna)
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-11-09 15:53:31 | Re: CLUSTER can change t_len |
Previous Message | Greg Stark | 2010-11-09 15:27:53 | Re: Protecting against unexpected zero-pages: proposal |