But the question is also interesting, such as the wildcard question (*) in select .
You want to make a flexible / scalable system. It works even with new columns. Hence you make a system that searches which columns exist (metadata) and excludes those that you are sure you will not need. Very well, you are creating a system that is concerned with data traffic (considering that the metadata is cached, of course) but not traffic (number of queries).
Only you pass this overhead to the application server, because as our friend Renan said, they did not create this in SQL (it would generate a lot of overhead for the DB, because although the logic is simple, it would need to be done in all types of consultation). Won on data, lost on performance. Of course, lost performance depends on the availability of your application. Systems that do not have problems with multiple / concurrent access have no problem with this.
Now, another note. What if the column that was added semantically has to go to the list of exceptions? Hum, and worse, if its meaning asks that other columns of the listed (brought by the select) enter the exceptions? Wow, what if ....
Well, this problem has a solution, called parameterization. the user or a configuration file - or another system - define the incoming and non-incoming fields of the query.
Problems? Yes, parametrization is one of the most debated paradigms of programming: how to parameterize, what to parameterize, when, and so on. Yes, because this generates harder code to create and maintain even though it decreases it.
Parametrization raises the overhead too ( mostly from the programmer ).
But all this could be solved with the wildcard (*); because the system you are doing is simple. Or just a few columns.