Re: ADD/DROP INHERITS

Ühel kenal päeval, N, 2006-06-08 kell 11:42, kirjutas Greg Stark:
> Hannu Krosing <hannu@skype.net> writes:
> 
> > Do you mean that in newer versions ALTER TABLE ADD COLUMN will change
> > existing data without asking me ?
> > 
> > That would be evil!
> > 
> > Even worse if ALTER TABLE ALTER COLUMN SET DEFAULT would do the same.
> 
> postgres=# alter table test add b integer default 1;
> ALTER TABLE
> postgres=# select * from test;
>  a | b 
> ---+---
>  0 | 1
> (1 row)
> 
> > > It was awfully annoying for users when that feature was missing. 
> > > Any non-linearities in the user interface like this
> > > end up being surprises and annoyances for users.
> > 
> > I would be *really*, *really*, *really* annoyed if an op that I expected
> > to take less than 1 sec takes 5 hours and then forces me to spend
> > another 10 hours on VACUUM FULL+REINDEX or CLUSTER to get performance
> > back.
> 
> I forget whether the developer managed to get it working without doing any
> table rewriting. In theory the table just needs to know that records that are
> "missing" that column in the null bitmap should behave as if they have the
> default value. But I seem to recall some headaches with that approach.

I remember that discussion, but I'm surprised that something got
implemented and accepted into core with so many unsolvable
problems/logical inconsistencies/new pitfalls.

for example - to be consistent, one should also make "ALTER TABLE ALTER
COLUMN col SET DEFAULT x" change each "default" value, no ? but how
should one know it for records which are updated, possibly in columns
newer than the one with changed DEFAULT. Or was a new default bitmap
introduced in addition to null bitmap ?

-- 
----------------
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