> This is just one of a few small adjustments that can be made to the grammar > to make everyone's life easier while still maintaining the spirit of NOSQL.
To be clear, I am *not* necessarily against making CQL3 closer to the ANSI-SQL as a convenience. But only if that doesn't compromise the language "integrity" and is justified. Adding a syntax with a well known semantic but without implementing said semantic fails that. Adding varchar size limits *with* its semantic would be acceptable (which is not saying that I personally care for it). And just so there is not misunderstanding, let's be clear that CQL3 will *never* be a proper subset of ANSI-SQL. Typically, CQL treats INSERT and UPDATE the same way, which breaks ANSI-SQL (though CQL never pretended being ANSI-SQL in the first place, so it doesn't break anything really). And that is not going to change, there is deep technical reason for that. > The semantics of how the grammar is implemented behind the scenes is > unimportant, what matters more is that an an ANSI-like interface should > have ANSI-like behavior where possible, So you are saying the most important part of the ANSI-SQL specification is the syntax grammar? I'll have to disagree. > Implementing a subset of ANSI is a good thing, changing ANSI-SQL not so > much. I have to say that I fail to see how not supporting joins (which we're not going to support any time soon, if ever, unless maybe you are suggesting supporting the join syntax but with a random semantic?) fails into "CQL3 is a subset of ANSI-SQL" but not supporting the size limit syntax of varchar fails into "changing ANSI-SQL". In fact I would say that not supporting the syntax in the first place is making it a subset, while supporting the syntax without the correct semantic (your suggestion) is breaking the ANSI spec (after all, the spec *does* specify that "the length in bits of the bit string is fixed and is the value of <length>" (SQL 1992, section 6.1 <data type>)). -- Sylvain
