Tom Lane <[EMAIL PROTECTED]> writes: > I thought we had agreed that the semantics of ADD INHERITS would be to > reject the command if the child wasn't already suitable to be a child > of the parent. Not to modify it by adding columns or constraints or > whatever. For the proposed uses of ADD INHERITS (in particular, > linking and unlinking partition tables) an incompatibility in schema > almost certainly means you made a mistake, and you don't really want > the system helpfully "fixing" your table to match the parent.
I didn't see any discussion like that and I find it pretty surprising. Personally I would have agreed. For partitioned tables you certainly don't want it to create new columns without warning you. But that's entirely inconsistent with the way inherited tables work in general. It seems to go against the grain of Postgres's general style to implement just the use case that's useful for a particular application rather than keep the features logically consistent with each other. Perhaps there should be an option when issuing the ADD INHERITS to indicate whether you want it to create new columns or only match existing columns. That would also give me a convenient excuse to skip all those NOTICEs about merging column definitions. Actually I think in the long term for partitioned tables Postgres will have to implement a special syntax just like Oracle and other databases. The user doesn't really want to have to manually manage all the partitions as tables. That imposes a lot of extra work to have to define the tables with the right syntax, maintain the constraints properly, etc. For the user it would be better to have a single property of the partitioned table that specified the partition key. Then when adding a partition you would only have to specify the key range it covers, not write an arbitrary constraint from scratch. Nor would you have to create an empty table with the proper definition first then add it in. -- greg ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org