I definitely vote for reserving words that are expected to be needed in the
future. It seems we have a pretty good chance of predicting most of the
syntactical needs for the next couple years (especially with suggestions
from common SQL variants), and the (hopefully) rare exceptions could get
their major version bumps.
2 and 3 feel like they would cripple CQL too much.
p
On Fri, Jul 22, 2011 at 6:10 PM, Eric Evans <eev...@rackspace.com> wrote:
>
> I just ran into an issue where CQL queries that were written at the time
> of 0.8.0 no longer work against 0.8.1. This was caused by r1130200
> (CASSANDRA-1709) which introduced ALTER support. The queries in
> question made use of unquoted terms for one of the newly added keywords
> ("type" in this case though any one of "alter", "table" or "add" would
> have caused the same problem).
>
> This case never occurred to me, but it is fairly serious since it breaks
> the expectation that code will remain backward compatible. The options
> I see are:
>
> 1. Bump the major of the language version when new keywords are added.
> 2. Set the expectation that unquoted terms could collide with future
> keywords.
> 3. Disallow the unquoted term variant (would require bumping the major
> once).
>
> #1 sucks because building out new features that would otherwise be
> backward compatible will result in a major bump. Looking at the roadmap
> and trying to reserve everything now that we'll need for the foreseeable
> future might make this less of an issue though.
>
> I have a feeling that #2 is easier said than done. So long as we're
> allowing the unquoted form, people will use it and be surprised when
> bit. Aside from that it seems OK.
>
> #3 is probably the most technically correct solution, but would make
> hand-crafted queries entered into interactive interpreters less
> friendly.
>
> Thoughts?
>
> --
> Eric Evans
> eev...@rackspace.com
>
>
