george.hames (9/14/2009)

---

Any of these behaviors would be acceptable if documented. Returning bad data without raising an exception is not acceptable, ever.

adjas (9/14/2009)

---

Any ideas?

george.hames (9/14/2009)

---

If you can't think of a case where it is sensible to use SELECT *, then I suspect that your experience is rather narrow.

george.hames (9/14/2009)

---

...there are times when you want to select ALL columns regardless of what they are. This would be particularly useful in a table function where you would not want to make any assumptions about what columns will be needed by applications referencing the function.

george.hames (9/14/2009)

---

Documented or not, the behavior being discussed is not acceptable. As I said earlier, asterisk expansion in any given context must be either static or dynamic. It can't be half and half. Acceptable behaviors would be:

george.hames (9/14/2009)

---

Any of these behaviors would be acceptable if documented. Returning bad data without raising an exception is not acceptable, ever.

george.hames (9/14/2009)

---

I'm sorry if my example was too abstract, but it really doesn't matter. The point is that if the syntax is allowed it should work in a predictable manner, or it should fail at run-time. Unpredicable results are not acceptable in a grown-up database. The existence of work-arounds does not mean that there is not a problem, and documenting the unpredicability doesn't make it acceptable.

Paul White (9/14/2009)

---

George, I do see your point, but remember that non-schema-bound views have always worked this way - it's not a special new thing. Metadata changes can affect non-schema-bound objects in unpredictable ways. It's difficult to see how SQL Server could sensibly be modified to change it either.

Matt Whitfield (9/14/2009)

---

There are 1000s of really stupid things you can do in any programming language... that's what best practice is all about I guess. I think the only important thing is not to ram it down people's throats...