>Referring back to the original email:
> > substring="-2:0" -- the last two characters // not possible currently
> > substring="0:0" -- the last character
>
>Shouldn't substring="-2:0" be the last *three* characters, as
>substring="-1:0" would be the last two?

Yes.

The fault is mine -- I'm a python programmer at heart, and the python
syntax is very similar:

string[start:end]
0 based, where negatives count backwards, end is *not* inclusive and
start or end omitted means start or end of the string.

So in python, "string"[-2:] == "ng"

The other issue with my poor examples was that I was also considering
not having 0 at all, and the last character of the string would then be
-1, as the first character of the string would be 1, but then thought
that changing as little of the current proposal as needed would be
better.

So in that version, string[-2:-1] would be the final two characters of
the string. If that's easier to use (it is for me, at least) then we
should change it to that instead. However -0 and negatives being
special in end, and not allowed in start is IMO worse than either of the
above.

That said, I also don't expect that substring will be frequently
implemented or frequently used to its full capacity. However I do still
believe it belongs in the cql context set, as it's useful for many
different types of data, in the same way that regular expression
searching is.

>The proposed substring function is really many functions in
>disguise. I reckon it is at least five distinct functions:

At least. But we don't really want 5 or more relation modifiers that
each cover a small part of the functionality of substrings, do we?

Rob