Thread: Re: [PATCHES] ADD/DROP INHERITS

Re: [PATCHES] ADD/DROP INHERITS

From
Greg Stark
Date:
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



Re: [PATCHES] ADD/DROP INHERITS

From
Tom Lane
Date:
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


Re: [PATCHES] ADD/DROP INHERITS

From
Greg Stark
Date:
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



Re: [PATCHES] ADD/DROP INHERITS

From
Hannu Krosing
Date:
Ü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