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 <robertmh...@gmail.com> > On Tue, Nov 9, 2010 at 10:50 AM, Viktor Valy <vili0...@gmail.com> wrote: > > 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 think the biggest problem is handling inherited tables properly, > 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 >
