Jean-Christophe Deschamps wrote: > Darren, > > At 02:19 28/09/2009, you wrote: > ´¯¯¯ >> So my proposed "<select list minuend>" is identical to the old "<select >> sublist>", and my addition is the optional EXCEPT plus list of not >> derived columns. >> >> Note that I'm not stuck on the keyword EXCEPT, but it should be a word >> that >> reads similarly. > `--- > > I would love to see that proposal accepted and someday implemented. > > I'm nonetheless worried by the fact that EXCEPT is already a keyword, > and is already part of the SELECT syntax.
I don't see that being a problem unless it would be ambiguous to the parser. Given that my proposed use can *not* be followed by the word SELECT it wouldn't be confused with "SELECT ... EXCEPT SELECT ...". In fact, reusing a keyword is actually advantageous as it means that no SQL which currently works on the DBMS will become illegal, which I think is very important, as we then have complete backwards compatibility. Although there might not be a problem anyway with a new word if the parser can interpret any code written to either the old SQL features or the new ones without ambiguity, and isn't strict to disallow the used word in places where it was allowed before. (As a side note, I'll mention that Muldis D doesn't really have any reserved words at all; you can name your entities anything and the parser can tell what is intended by context, same as humans, and the parser is fairly simple single-pass.) Generally speaking, I think SQL already uses the same keywords in multiple uses sometimes; for example, "WHERE foo BETWEEN 5 AND 8" is not the same "AND" as with the usual boolean conjunctions. > Maybe another verb less likely to pose problem would be easier to > manage. What would you think of: > > SELECT ALLBUT foo FROM t ... > > Just a thought. That could work as a simpler form where the result columns are simply input columns and no derived expressions, but my proposal would keep the full flexibility of the ... in "SELECT ... FROM ..." which I think is what people would expect to be able to do. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
