On Wed, 14 Aug 2013 14:57:19 -0500 "Marc L. Allen" <[email protected]> wrote:
> I'd actually like a compromise. Allow GROUP BY to accept a derived > name if no base name exists. I realize that's against spec, but > there's no ambiguity (as it otherwise errors out), It would also mean the query's meaning could change if the underlying DDL changed. If the column were later added (say, to a view) that happened to have the same name as that of the alias in the query, the DML would silently start using the "base" name instead of the derived one. That's not normally the case in SQL. Normally, adding a column to a table/view cannot change the query's meaning. Either the query is unaffected, or the new column introduces ambiguity (in the presence of a join) that causes it to return an error. The only safe and proper thing is for GROUP BY to refer to the column names as known to the database, not to aliases mentioned in the query. > and does make it much nicer when the derived column is a hairy > expression that I end up needing to replicate in the GROUP BY clause. We do need a better language, yes. --jkl _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
