On Sun, 23 Jan 2000, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I wonder if we should throw out a NOTICE when we drop some
> > characteristic of a table?
>
> The problem is mostly that the code doesn't even *know* that it's
> dropping data. If we add code to find the info that's getting lost,
> it's probably little more work to add code to copy it.
>
> I'm of two minds about this. Peter is an energetic new contributor
> and we'd be really foolish to discourage him (I was there not very
> long ago myself). And a limited DROP COLUMN capability is better
> than none at all, so long as its limitations are well-documented.
IMHO, put out a BIG NOTICE if someone issues the DROP COLUMN command:
Do not expect your table to look like what you used to have!!
This has nothing to do with discouraging a contributor ... this has to do
with maintaining QA through peer-review ... it would have taken Peter *as
long* to send his note out 24hrs *before* commiting the changes and would
have at least spur'd on a possible discussion of a better way of dealign
with the whole OID situation ...
Look at the last major patch we threw in from Alfred ... he posted and
asked for comments ... Tom, I believe it was you that send back a few
concerns ... he addressed them and posted for review a *second* time
before we committed it. After committing, we found a bug ... someone else
wanted to revert that patch, but *at that point* it would have been
inappropriate to do, since it had been reviewed twice and considered good
for inclusion ... if Alfred couldn't have fixed the problem adequately
after a few days, okay, then revert it, but at least give him a chance to
fix that which he wrought ...
In Peter's case, there was no review ... just slap it in and pray ;(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org