mperdoni

Can it go one meme-step further and automate our jobs away? ;)

Ultimately, if a bug in a library causes issue with your program, and your company loses $X, your superiors will not give a shit. You have the burden of responsibility for the program.

For common major libraries used worldwide in enterprise products, you are right in that there is an element of trust. They are made by people much faster/better/stronger than most of us. If all else fails, the sheer magnitude of people using it is a small insurance policy, as disastrous issues will probably be quickly apparent. That still doesn't absolve you of responsibility, but the overall risk is usually pretty low.

A segment of code on SO, or a weeny niche library? You only have your noggin to vouch for its stability and accuracy.

There seems to be a suspicious rise of acceptance for this "practice". It's very concerning. I've never found a SO answer to be copyable, they are usually wrong or flawed.

Usually have to dig in all the responses to get a balanced overview, then apply those concept(s) to your problem at hand....

Here's a few reasons why when you finalize a query, you select only the necessary columns (non-exhaustive list):

- Reduce uneccessary IO / resource strain, as you said

- Predictability; consuming program receives data in the same order, every time

- If the DBA adds additional columns to the table, it doesn't hose downstream consumer processes

- Easier to debug if some problem does arise.

- Clarity, if you are only using a few columns from a large table. I might just be getting old though ;)

Data should be served in the simplest, most robust manner.

It should be easily consumed by other services, with little extra effort from the programmer.

If you use Select *, you either accept the possibility of it breaking unexpectedly, or have to write logic within the consuming service to deal with that. If the problem can be eliminated by the DB/query itself, it should be.