At 10:27 PM 1/22/00 -0500, Bruce Momjian wrote:
>> Did I miss a discussion here on implementing this, and how? Sounds to me
>> like a week and a bit before planned beta, an *incomplete* feature has
>> been shoved into the source tree with zero forewarning or discussion ...
>>
>> 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.
>
>Everyone asks for this, and if it does only %70 of the job, that is fine
>as long as the manual page says so.
I'm sorry, but his current hack results in silent failures.
Personally, I think he should've asked for answers to his questions
first - i.e., how do you find out which relations are subject to
foreign key restraints (implemented via triggers)?
Allowing one to drop columns with silent failure is hardly the
hallmark of a professional piece of software. What has impressed me
about the Postgres effort in the year that I've been tracking it (though
sadly not contributing to it), has been the concentration on professional
implementation of features, and the concentration on improving stability
and reliability.
"copy to a table, drop the column, copy back" - heck, I could do that
with a script file to be fed into psql. An internal implementation has
to be far better to be considered a piece of a professional RDBMS, I'm
afraid.
I'm not saying that this isn't the proper basis for the feature, only
that sure, that's easy to do internally or externally, and that isn't
the problem.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.