Thread: Re: [PATCHES] ADD/DROP INHERITS
Also a couple other thoughts: I have a bit of uneasiness about the "use the first hole" method for adding parents. Namely it makes the whole thing a bit unpredictable from the user's point of view. The holes aren't user visible so they have no way to know when they add a parent where in the list of parents it will appear. And when you add something to a list don't you usually expect it to appear last? It's not exactly least-surprise compliant to have it appearing in the middle of the list of parents. But perhaps it's just worth those downsides to keep DROP/ADD a noop in more cases. But on that note I'm starting to have second thoughts about the one-wayness of attislocal->1. It means if you ever drop a partition all the columns will become attislocal=1 forevermore, even if you re-add the partition. It also means if you create partitions independently and then add them they behave differently from if you create them as inherited tables. I'm thinking that in the partitioned table use case this will get in the way of dropping columns from a partitioned table. You'll essentially be forcing users to drop the column manually from every child. Maybe it would be better to set attislocal=0 if the attinhcount goes from 0->1? Otherwise if we don't allow new columns to be created in ADD INHERIT then we're forcing users to treat all their columns as locally defined. -- greg
Greg Stark <gsstark@mit.edu> writes:
> Maybe it would be better to set attislocal=0 if the attinhcount goes from
> 0->1?
That just moves the surprises to other cases. I think I'd prefer to err
in the direction that can't cause unexpected data loss (due to columns
being dropped that perhaps should not have been).
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Greg Stark <gsstark@mit.edu> writes: > > Maybe it would be better to set attislocal=0 if the attinhcount goes from > > 0->1? > > That just moves the surprises to other cases. Sure, but if we're not allowing new columns to be created, those surprise cases now include virtually every case. At least for partitioned tables. > I think I'd prefer to err in the direction that can't cause unexpected data > loss (due to columns being dropped that perhaps should not have been). I figured that was the thinking. Perhaps what's really needed is to move away from the idea of automatically deciding whether to drop child columns and never drop child columns unless the user specifies some keyword which would force them to always be dropped. It seems to me that trying to distinguish "locally defined" versus "only inherited" is too subtle a distinction and depends too much on what the user considers a local definition. What's "locally defined" seems to vary depending on the application. -- greg
Ühel kenal päeval, L, 2006-06-10 kell 13:06, kirjutas Greg Stark: > But perhaps it's just worth those downsides to keep DROP/ADD a noop in more > cases. I don't think that "keeping DROP/ADD a noop in more cases." is a goal here. It may be a kind of semi-useful metric of design goodness, but never a goal in itself. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com