Re: [HACKERS] Happy column dropping
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Happy column dropping |
Дата | |
Msg-id | 388B7AF7.7AFBFFB7@tm.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] Happy column dropping (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Happy column dropping
|
Список | pgsql-hackers |
The Hermit Hacker wrote: > > On Sun, 23 Jan 2000, Bruce Momjian wrote: > > > I think we are spoiled with Tom, Jan, and Vadim who just show up and > > produce 100% functional patches the first time. Some people go at it in > > different ways. Eventually it all gets working. I can't tell you how > > many times I have added a feature or fixed something, and then had Tom > > Lane or Vadim come along and fix my fixes. > > 2 points: > > a) 100% functional patches *after* extensive discussion It assumes that you do all your actual coding and code reviewing yourself while hiding the code, i.e. the (alledged) *BSD way. The "release often, release early" school of OS tells people to show even premature code in hope of getting more/faster eyballing. He could have done it by posting patches for discussion, but I can't see the real difference here. What I think he is doing here is one-to-one move the FAQ recommendation for drop column to backend. And then move on from that to cover the areas of renumbering colums and keeping related constraints intact the FAQ glossed over. It could possibly be done by marking the column deleted and doing the compression/renumbering during vacuum , or by locking the table and compressing each page in-place if space is a concern or maybe several other ways. The existence of several ways to do it should not discourage people from actually adding the drop column feature to postgres > b) Peter's change wasn't a fix I was'nt a _bug_ fix, it was a usability fix and likely SQL 92 compatibility fix. ------------- Hannu
В списке pgsql-hackers по дате отправления: