| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: ADD/DROP INHERITS |
| Date: | 2006-06-07 21:11:53 |
| Message-ID: | 17474.1149714713@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> In this situation, I think it's entirely reasonable to expect the user
>> to do any needed ALTER ADD COLUMN, CONSTRAINT, etc commands before
>> trying to attach a child table to a parent. Having the system do it
>> for you offers no functionality gain, just a way to shoot yourself in
>> the foot.
> Well if that's the consensus feeling then it certainly makes my life easier.
Well, one reason for my position is exactly to make your life easier.
I think that making ADD INHERITS do all these other things automagically
is lily-gilding, or at least implementing features not shown to be
needed. Let's make it do the minimum needed for the use-cases cited so
far --- we can always add more functionality later, *after* it's proven
needed.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2006-06-07 21:18:45 | Re: That EXPLAIN ANALYZE patch still needs work |
| Previous Message | Martijn van Oosterhout | 2006-06-07 21:07:28 | Re: That EXPLAIN ANALYZE patch still needs work |