Re: TODO Alter Table Rename Constraint
От | Viktor Valy |
---|---|
Тема | Re: TODO Alter Table Rename Constraint |
Дата | |
Msg-id | AANLkTimrwLHbtvaYH-MzSwkgu=aChcfsmPQ3gx5g_iW0@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TODO Alter Table Rename Constraint (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: TODO Alter Table Rename Constraint
|
Список | pgsql-hackers |
Thanks for your answer!
I'm not really familiar with inheritance, but I wonder how this issue is handled in other cases, for instance renaming an index, which invokes internal a constraint rename too. Is that relevant or is the renaming of constraints so special?
Is there a solution for the test-cases you have posted? Or is this yet a problem?
Viktor
2010/11/9 Robert Haas <robertmhaas@gmail.com>
On Tue, Nov 9, 2010 at 10:50 AM, Viktor Valy <vili0121@gmail.com> wrote:I think the biggest problem is handling inherited tables properly,
> 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?
especially in complex inheritance hierarchies where there are
multiple, separate paths from the top of the hierarchy to the bottom.
See here for a couple of relevant test cases:
http://archives.postgresql.org/pgsql-hackers/2010-07/msg01570.php
I believe that the rename needs to fail if any table in the
inheritance hierarchy rooted at the target table also inherits the
constraint from someplace outside that hierarchy; or if any table in
that hierarchy has a local copy of the constraint that got merged with
the inherited one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: