incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Prendergast>
Subject Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
Date Tue, 05 Mar 2013 07:25:44 GMT
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

Implementing a subset of ANSI is a good thing, changing ANSI-SQL not so

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.


On Mon, Mar 4, 2013 at 7:08 PM, Sylvain Lebresne <>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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message