Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
От | Bruce Momjian |
---|---|
Тема | Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) |
Дата | |
Msg-id | 200607020200.k6220ln19216@momjian.us обсуждение исходный текст |
Ответ на | ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
|
Список | pgsql-patches |
Patch applied. Thanks. I ran pgindent on the tablecmds.c block of code, and cleaned up some boolean assignments. There are a few XXX comments still in the code so someone should look at those questions and either modify the code or remove the comments. --------------------------------------------------------------------------- Greg Stark wrote: > > I cleaned up the code and added some more documentation. > > I think I've addressed all the concerns raised so far. Please tell me if I've > missed anything. > > There were a few tangentially related issues that have come up that I think > are TODOs. I'm likely to tackle one or two of these next so I'm interested in > hearing feedback on them as well. > > . Constraints currently do not know anything about inheritance. Tom suggested > adding a coninhcount and conislocal like attributes have to track their > inheritance status. > > . Foreign key constraints currently do not get copied to new children (and > therefore my code doesn't verify them). I don't think it would be hard to > add them and treat them like CHECK constraints. > > . No constraints at all are copied to tables defined with LIKE. That makes it > hard to use LIKE to define new partitions. The standard defines LIKE and > specifically says it does not copy constraints. But the standard already has > an option called INCLUDING DEFAULTS; we could always define a non-standard > extension LIKE table INCLUDING CONSTRAINTS that gives the user the option to > request a copy including constraints. > > . Personally, I think the whole attislocal thing is bunk. The decision about > whether to drop a column from children tables or not is something that > should be up to the user and trying to DWIM based on whether there was ever > a local definition or the column was acquired purely through inheritance is > hardly ever going to match up with user expectations. > > . And of course there's the whole unique and primary key constraint issue. I > think to get any traction at all on this you have a prerequisite of a real > partitioned table implementation where the system knows what the partition > key is so it can recognize when it's a leading part of an index key. > > [ Attachment, skipping... ] > > > -- > greg > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: