Sylvain, All I'm trying to do is make Cassandra work with existing ETL, ORM & desktop tools a bit better.
I think that is a worthy cause. ap On Tue, Mar 5, 2013 at 8:20 PM, Sylvain Lebresne <sylv...@datastax.com>wrote: > > 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 >