Re: [HACKERS] Well, then you keep your darn columns
От | Ed Loehr |
---|---|
Тема | Re: [HACKERS] Well, then you keep your darn columns |
Дата | |
Msg-id | 388C9664.1D975D2D@austin.rr.com обсуждение исходный текст |
Ответ на | RE: [HACKERS] Well, then you keep your darn columns ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: [HACKERS] Well, then you keep your darn columns
Re: [HACKERS] Well, then you keep your darn columns |
Список | pgsql-hackers |
Tom Lane wrote: > Let's see: DROP COLUMN would have to mark the column invisible, remove > any associated constraints (particularly NOT NULL) and indexes, and > it'd be done. The parser would then have to ignore the column when > doing column name lookups or expansion of '*', and it would have to > insert a NULL value for the column when transforming INSERT or UPDATE. > And that'd be just about it. I like it. How would you handle multi-column indices that included the column being dropped? E.g., create unique index foobar on mytable(foo,bar); where the 'bar' column is then dropped... Dropping all of that index would seem to be problematic. Cheers, Ed Loehr
В списке pgsql-hackers по дате отправления: