News for hackers. Stuff that matters.

A comment on Friendlier SQL with DuckDB. Parent comment

Re:Friendlier SQL with DuckDB by munk-a on Thursday May 12, 2022 @01:43PM (#31357476)
I've always viewed SELECT * as a convinence for schema discovery and a huge bonus for subqueries - our shop excludes its use at the top level in production due to the danger of table definitions changing underneath... but we happily allow subqueries to use SELECT * so long as that column list is clearly defined before we leave the database.

Worst, by far, than a column you didn't expect being added is a column you did expect being removed. Depending on how thorough your integration tests are (and ideally they should be pretty thorough) you could suddenly start getting strange array key access (or object key unfound) errors somewhere on the other side of the codebase.

[ Parent | on HN ]
Re:Friendlier SQL with DuckDB by throwawayboise on Thursday May 12, 2022 @02:30PM (#31358233)
Yeah I tend to use "select *" in interactive queries when I'm working out what I want, but then write explicit column names in anything going into production. This helps with the column-being-removed case, as the query will fail immediately selecting a nonexistent column, whereas "select *" will not fail and the error will happen somewhere else.
[ Parent | on HN ]