Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
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 [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] table/index fillfactor control, try 3
Patch applied. Thanks. Catalog version updated. --- ITAGAKI Takahiro wrote: > This is the 3rd revised fillfactor patch. > Now, AM specific options are stored in pg_class.reloptions as text[]. > Also, some bugs are fixed. It passed all regression tests. > > > Tom Lane <[EMAIL PROTECTED]> wrote: > > > An opaque bytea won't do though. What I'd suggest is something real > > close to the format used for GUC parameters in ALTER DATABASE SET and > > ALTER USER SET, ie, pairs of keyword/value strings. This way pg_dump > > doesn't need very much smarts about what the values are that it's > > dumping. > > The column format of options is changed from bytea to an array of text, > so re-parsing is needed every time a connection accesses a relation. > I changed to write pre-parsed options into pg_internal.init, but AFAICS, > only system relations are written in it. If we will find the parsing > is slow, it might be good to store options for user relations, too. > > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Bruce Momjian <[EMAIL PROTECTED]> writes: > 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. So this patch was by no stretch of the imagination ready to apply, but you did it anyway. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > 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. > > So this patch was by no stretch of the imagination ready to apply, > but you did it anyway. Right. What is your next question? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> So this patch was by no stretch of the imagination ready to apply, >> but you did it anyway. > Right. What is your next question? Perhaps "why is the buildfarm failing" would be appropriate. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
