Re: Would be really nice if...

Haximus wrote:
> Ed Prochak wrote:
> > but when you present the reciept for 13 donuts and the boss only
saw
> > 12, you'll be waiting a long time for that reimbursement check.
>
> You'd lose sleep over compensation for a donut? ;)

It's your analogy, not mine. I just pointed out the failure in your logic.
>
> > Just admit it. select * is not safe.
> >
> > Does no one practice defensive programming anymore?
> >
> > One guideline I've tried to follow in my development practice:
> > It's not how well it work when it works that's important,
> > but how well it works when it doesn't work that's important.
> >
> > the "select * exclude" syntax doesn't buy you any protection over
the
> > "select *" but an explicit list Always gets the data it expects.
> > Proponents of "select * exclude" are arguing for saving a little
> > programmer time now while leaving a big window for future errors.
>
> Like anything there are advantages and disadvantages, if the
perception
> is that it's a disadvantage -- don't use it.

It is not perception. Either it works or it doesn't. In the face of table changes, neither "select *" NOR "select * exclude" works.

>
> I'm just reflecting on other types of systems for filtering and how
they
> handle inclusion/exclusion and specifying sets, for example Apache
> access control allows you to specify access with "allow from all,
deny
> from xxx" or conversely "deny from all, allow from xxx" type
> functionality for describing sets. It basically the same concept.

It might be nice for adhoc queries, but not in production code. And yes I'm well aware of the concepts of include/exclude features in some products. They work best went the number of options is know and usually finite.
>
> Take for example queries where you want everything except a tiny
subset,
> so logically you create your query based on what you DON'T want and

> select the remainder. By Fitzy's logic we should write queries that
> specify everything we do want, even if that means a huge cumbersome
> query to account for everything, instead of a simple elegant query to

> select everything except what you don't want. Of course, nobody in
> their right creates queries that way.
>
> Now just extend that logic to selecting column sets.

Again your logic is flawed. We don't select attributes based on conditions.
Relations just don't work that way.

It is an unsafe construct. Adding it to the SQL standard won't kill SQL, but using it in production applications may cause some serious side effects. That same side effects as select *. So what I'm saying is not just use with caution, but use with EXTREME CAUTION.

Ed Received on Mon Feb 28 2005 - 11:46:31 CST