Re: Would be really nice if...

"Serge Rielau" <srielau_at_ca.ibm.com> wrote in message news:385v3eF5iovfqU1_at_individual.net...
> Haximus wrote:
>>
>> As with any 'feature' usage is optional, you are not OBLIGATED under
>> threat of a gun to your head to use it, if it offends your sensibilities
>> or personal tastes. Morgan's example is really stretching it if that's
>> the only thing he could come with... that there are considerations when
>> modifying table structures in any situation is an IMPLIED NO-BRAINER.
>> Using a feature suggests that you know what the hell you are doing with
>> it in the first place... and understanding it's effects.
>>
>> I'm not sure what the big conceptual problem is with it, it's simply an
>> alternate method to specify a column select list... that's about the
>> grand summation of it.
> I challenge the fact that users undertsand what they are doing. In my
> experience, and across vendor borders, thie is simply not true.
> There are plenty of voices claiming that SELECT * was bad idea to begin
> with. It causes endless grief w.r.t. schema evolution.
>
> Having said that I don't really think that an EXCLUDE option makes things
> any worse than they already are.
> But while you're at it the next step will be an EXCLUDE syntax on INSERT
> to avoid having to specify a column list when dealing with columns that
> are not updatable... and so on.
> It's a bit of a complex-instruction set vs. reduced instruction set
> problem. Is it worth bloating the language further because of syntactic
> convenience given the existence of modern tooling?

There is no reason to extent the exclusion option to all dml where it could also be applicable considering that it was only intended as productivity feature (or laziness-assistant) in the context of ad-hoc query evelopment, but not something you would embed or hardcode in applications. It like SELECT *, people generally don't put such things into production unless there is a good reason to do so. As for bloating the language, I don't think adding a paragraph to the existing 1808 pages of the 10g SQL Reference is making a significant contribution to bloat ;) <sracasm intended> Received on Fri Feb 25 2005 - 04:17:30 CST