Re: Happy column adding
От | Peter Eisentraut |
---|---|
Тема | Re: Happy column adding |
Дата | |
Msg-id | Pine.LNX.4.21.0001261539580.416-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2000-01-25, Tom Lane mentioned: > > IIRC,there were some reason that default for new column had been rejected. > > Well, yeah: wouldn't you expect that "ADD COLUMN x DEFAULT 42" would > cause every row currently existing in the table to acquire x = 42, Sure. But whatever happened to pg_exec_query_dest("update <tablename> set <newcolname> = <default>") This is what users would have to execute anyway, right? Look at this: => create table test1 (a text); => insert into test1 values ('blah'); => insert into test1 values ('blah'); => insert into test1 values ('blah'); => alter table test1 add column b serial; => select * from test1; a | b ------+---blah | 1blah | 2blah | 3 (3 rows) Not good? > rather than x = NULL? In fact that would *have* to happen to allow > constraints to be added; consider ADD COLUMN x DEFAULT 42 NOT NULL. Or how about (continuing the above): => alter table test1 add column c int not null; ERROR: ALTER TABLE: adding NOT NULL attribute to non-empty table requires a non-NULL default value > The only way to make that happen is for ADD COLUMN to switch over to > an implementation that rewrites all the tuples. Which I think is the > right way to go ... but per this discussion, it's not a trivial fix. So what's the above doing? Seriously, is there silently creeping heap corruption I'm not seeing? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: