Thread: Issues in partitioning - constraint dependency
I'm working on partitioning syntax, amd encountered a dependency issue. When we define partition, also create an implicit CHECK constraint. The constraint should be kept until the pg_inherits entry is removed. But we cannot have a dependency from the constraint to the inheritance. An idea is adding pg_inherits support into the common dependency module, but it didn't work as far as I tested. The code will be cleaner if we can do so, but we don't now. Are there known issues here? Another idea is storing the constraint as an independent constraint in pg_inherits. When we cache a relation, merge CHECK constraints in pg_constraint and pg_inherits. It could solve the issue, but we will have duplicated codes. The third idea is just saying "Don't do that" in the documentation... What should we do for it? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
On tis, 2009-11-10 at 16:22 +0900, Itagaki Takahiro wrote: > I'm working on partitioning syntax, amd encountered a dependency issue. > When we define partition, also create an implicit CHECK constraint. > The constraint should be kept until the pg_inherits entry is removed. > But we cannot have a dependency from the constraint to the inheritance. I'd say, don't worry about it for now. Eventually, we will probably want to replace the partitioning by CHECK constraint by some other mechanism (like operator classes or something), at which point we will want to come up with a more robust catalog representation. The mandate at the moment, I suppose, is just to hide the existing functionality behind a special purpose syntax to make the future internal changes easier.