Feature Request: pragma to curb bad column expectations
(1) By Ryan Smith (cuz) on 2020-06-02 21:19:29 [source]
In a recent thread I related the human error of bad expectations regarding column ordering. It's a song I know very well from having to recite it often.
Would it be feasible to add a pragma like "reverse_unordered_selects" but perhaps named: "reverse_asterisk_column_names" or perhaps "random_wildcard_columns"
I believe the idea is obvious. Perhaps obfuscating both un-aliased column names and unspecified positioning.
I often find contributing programmers who forego the SELECT column request specification, and introducing this pragma will help make these egregious habits visible before production switchover.
And while I'm in the asking chair... Please note our continued plight for pragma "strict_mode". :)
(2) By Keith Medcalf (kmedcalf) on 2020-06-02 23:54:01 in reply to 1 [link] [source]
This would be non-compliant with the standard. The standard requires that if a "returned column" refers to table column and is unambiguous, that the returned name, unless overridden by an AS clause, be the bare column name.
So you would be free to shuffle-about the column ordering or the names of computed columns, but bare columns must be named with the bare column name (where that name is unambiguous).
(3) By Simon Slavin (slavin) on 2020-06-03 00:40:48 in reply to 1 [link] [source]
SELECT * in production code is useful for debugging and messing about in the CLI tool. But can lead to unexpected results in production code, for example if you add new columns to a table late in the development process. Never do it in professional code. Always provide column names.
Also, I don't think I've seen a rule about column order for
*. Every implementation I've seen puts them in definition order but I don't think it has to.