John Crenshaw wrote: >> There's nothing wrong with that. > > Not unless style counts for something. X is Y looks far too much like X > as Y for my taste. I'd rather do a little extra typing to have clear > logic than to have clearly unclear code like that. My first thought when > I saw this was "doesn't he mean AS?" If I saw something like this in my > code I'd expect some major comments to clarify why the code really does > mean IS and not AS.
I agree with you regarding syntax and style. My post was addressing just the "You just want a result set of true/false values?" comment as if that was saying "what reason is there to want a result set of true/false values"; it was not addressing the syntax/style issue. Regarding syntax and style, I would advocate that simple "=" comparisons being able to test for null would be superior, with the conception being that null is treated as a special marker that is not equal to any other value but is equal to itself. This is the semantics that SQLite's new "IS" follows I believe. And then you don't need any "is"/"as" confusion. -- Darren Duncan > -----Original Message----- > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Darren Duncan > > Jay A. Kreibich wrote: >> On Tue, Oct 27, 2009 at 04:15:57PM +0000, Tom Sillence scratched on > the wall: >>> because I really want to write neat queries like: >>> >>> select col1 is col2 from table >> Are you sure? You just want a result set of true/false values? > > There's nothing wrong with that. Booleans are values like anything > else, and > one should be able to store them as field values and return them in > rowsets. > And very useful in practice, when one considers all the facts one might > want to > store that are commonly expressed as true/false, such as in a users > table column > named "may_login" or "is_moderated". -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
