Обсуждение: Issues in partitioning - constraint dependency

Поиск
Список
Период
Сортировка

Issues in partitioning - constraint dependency

От
Itagaki Takahiro
Дата:
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



Re: Issues in partitioning - constraint dependency

От
Peter Eisentraut
Дата:
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.