I’d like to thank Claude Rubinson for his thoughtful critique  of my remarks in reference  on nulls and three-valued logic (3VL). Clearly we’re in agreement on the major issues; as Rubinson says, “I agree with Date that three-valued logic is incompatible with database management systems. ” We also agree that null isn’t a value; as Rubinson says, “SQL defines null not as a value but a flag. ” However, I’d like to comment on three specific issues arising from Rubinson’s article. Note: All otherwise unattributed quotes are from that article. Note too that I follow Rubinson (for the most part) in using the SQL terminology of tables, columns, and rows. THE ORIGINAL EXAMPLE The database I used as a basis for my examples in reference  looked like this (S = suppliers, P = parts): In this database, “the CITY is null ” for part P1. What’s more (as I said in reference ): Note carefully that the empty space in [the] figure, in the place where the CITY value for part P1 ought to be, stands for nothing at all; conceptually, there’s nothing at all?not even a string of blanks or an empty string?in that position (which means the “tuple ” for part P1 isn’t really a tuple, a point I’ll come back to [later]). I then posed the query “Get SNO-PNO pairs where either the supplier and part cities are different or the part city isn’t Paris (or both), ” and offered the following as “the obvious SQL formulation of this query”: Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright held by the author(s)
To submit an update or takedown request for this paper, please submit an Update/Correction/Removal Request.