Hi Sylvain, I disagree. Actually, CQL3 is really close to being a faithful subset of ANSI-SQL, which is rather exciting.
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. 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, if only for the greater good of humanity! Implementing a subset of ANSI is a good thing, changing ANSI-SQL not so much. On this specific issue, Cassandra's behavior subsumes what would be expected of say VARCHAR(256) or VARCHAR(MAX) so throwing an exception to client apps when they ask for either of these is incorrect. There are a handful of minor disparities whereby the ANSI spec has been changed (vs. not implemented) - I'm making a list of the former and I'll put it into JIRA under one task. ap On Mon, Mar 4, 2013 at 7:08 PM, Sylvain Lebresne <sylv...@datastax.com>wrote: > > When creating a table in all ANSI-SQL compliant RDBMS' the VARCHAR > datatype > > takes a numeric parameter, however this parameter is generating errors in > > CQL3. > > > > CQL3 is *not* ANSI-SQL compliant and will never be. It's not even SQL. > > > > > I would like to propose that the column length be allowed in the grammar > > (but ignored by cassandra), allowing better ANSI-SQL client > compatibility. > > > > I agree with Ed and disagree with your proposal. Allowing a length > constraint > but not respecting it would only help people to shoot themselves in the > foot, as > they would be led to believe Cassandra does validate the length where it > doesn't. > > If would be acceptable to add the length only if we do respect it. Which is > something we could do, though adding it "just" to make it close to ANSI-SQL > honestly doesn't interest me much (adding it because it's useful would be a > better argument however) because again, CQL is not SQL. In particular, you > don't model application with CQL the same way you do with SQL, and so using > a SQL application in CQL without modification is not a good idea. Besides, > I doubt any non-trivial SQL application could be used as is in CQL, due to > the > lack of join for instance. > > -- > Sylvain >
