RE: [HACKERS] Happy column dropping

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] Happy column dropping
Дата
Msg-id NDBBIJLOILGIKBGDINDFIEELCCAA.Inoue@tpf.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Happy column dropping  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы RE: [HACKERS] Happy column dropping  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Okay, my turn here ... I vote for this to be *reverted*!!
> 
> > I disagree.  First, it is on the TODO list, so it is open game.  Second
> > it is not throughout all the code, it only gets activated if someone
> > executes the command.  Third, I don't know of any time limit that
> > features have to be implemented a certain number of weeks _before_ beta
> > starts.
> 
> I agree with Bruce.  There's no risk of this breaking anything else,
> AFAICT, so if it doesn't work there's no harm done.  I hope Peter is
> going to clean it up more before beta, but why shouldn't he push out
> what he has for review and criticism?
>

I agree with Marc. 
DROP COLUMN feature should be discussed before implementing it.

We can live without DROP COLUMN feature.
All we have to do is to ignore the column.
Why should we have a complicated implementation for the feature
without any discussion ?

Anyway I have 2 basic questions.

1) Is the * 2x disk usage *  implementation really needed ?
2) Why rename() ?   I don't trust rename() at all in transaction control.   The first thing we should do it to change
relname-> relation file   name mapping in order to avoid calling rename(). 
 

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Unique constraint for inherited tables?
Следующее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] foreign keys?