Re: ALTER TABLE modifications

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: ALTER TABLE modifications
Дата
Msg-id Pine.LNX.4.44.0311141745130.4276-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: ALTER TABLE modifications  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ALTER TABLE modifications  (Hannu Krosing <hannu@tm.ee>)
Список pgsql-patches
Tom Lane writes:

> I believe the consensus was that automating what you could do by hand
> is still a step forward.

I don't recall that, but if so, I would like to revisit that consensus.

AFAICT, this patch does not buy us anything at all.  It's just a different
spelling of existing functionality.  We have never done that before.  It
just makes the system harder to maintain and use.  All commands should be
reasonably independent, or at least add some functionality of their own.

> It clearly would be better if we could relabel the logical column
> position after finishing the whole process, but I agree with Rod that
> that is an independent patch.  Combining them into one mega-patch
> doesn't sound like good engineering.

Good engineering would be if the logical column number patch comes first.
We cannot possibly leave this patch as is.  People expect in-place column
changes.  Things will break left and right, users will complain all over
the place if we offer a way to change a column, but yeah, by the way it
changes the structure of the table as well.  We've had these kinds of good
idea/right direction/better than nothing approaches in areas like DROP
COLUMN and CLUSTER already, and they were no good.  Except in this case,
"better than nothing" doesn't even apply, because there is already
something.

--
Peter Eisentraut   peter_e@gmx.net


В списке pgsql-patches по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: ALTER TABLE modifications
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] heads up -- subtle change of behavior of new initdb