Ü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
