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 19:52:39 GMT

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.


On Tue, Mar 5, 2013 at 8:20 PM, Sylvain Lebresne <>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
> To be clear, I am *not* necessarily against making CQL3 closer to the
> 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
> the same way, which breaks ANSI-SQL (though CQL never pretended being
> 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

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