On Thu, Feb 10, 2011 at 09:35:04AM -0600, Puneet Kishor scratched on the wall:
> that code would be very complex to cover all the possible cases. The > simplest solution is to depend upon AS aliasing To be clear, that's not an excuse the development team is using to avoid writing a hard bit of code. The SQL standard leaves column names undefined in the absence of a column alias (e.g. "AS" phrase). In other words, the database is free to do its best, but it is really up to the developer to strictly define names, via AS, if the names are relevant (i.e. used in code). (The wisdom of using names as column identifiers is a whole different argument.) Consider your own example. Is "a" really the correct output? What about "x.a"? Or "main.x.a"? If you feel the need to quote a column name, such as "[a]", why shouldn't the database feel it is proper to quote it back at you? What if there is both an "x.a" and a "y.a" column from an "x JOIN y" operation? Should the columns be "a" and "a", or should they promoted to be more specific? What about a sub-select that has an "a AS a" output specification, where it is an alias that just happens to be the same as a column, but it is no longer a source-column reference? What about "a+1 AS a" where any source-column association (and therefore table and database association) is specifically broken? For almost any naming scheme one can come up with, it is fairly easy to find odd edge cases that add dozens of extra "but", "unless", "except" rules to your naming convention. Your rule set quickly becomes so huge and fragile, you might as well treat the naming convention as undefined. And, of course, the naming rules would be product-specific (Some DBs have schema name-spaces, some don't. Some have table-spaces, some don't. Some can access multiple databases, some can't.), meaning every database is going to do it differently anyways-- which is exactly why it isn't in the standard. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
