RE: [HACKERS] Well, then you keep your darn columns
От | Ansley, Michael |
---|---|
Тема | RE: [HACKERS] Well, then you keep your darn columns |
Дата | |
Msg-id | 1BF7C7482189D211B03F00805F8527F748C488@S-NATH-EXCH2 обсуждение исходный текст |
Список | pgsql-hackers |
All the databases that I've worked on (that actually have the ability to drop columns) generate an error if the column to be dropped is part of a key, and I think that is sound behaviour. MikeA -----Original Message----- From: Ed Loehr To: Tom Lane Cc: Hiroshi Inoue; Peter Eisentraut; pgsql-hackers@postgreSQL.org Sent: 00/01/24 08:13 Subject: Re: [HACKERS] Well, then you keep your darn columns 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 по дате отправления: