 |
 |
>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