Finn Bear

@tobiemh Good idea, I've added some test cases :) FYI it's probably easier to merge #241 first (if at all), and then I'll fix the conflicts with this PR. It...

> Now that #241 is merged, I presume this PR needs a couple of changes @finnbear? Absolutely! Just made the required changes, improved the tests, and also fixed an oversight...

> @finnbear just been looking through this a little more. It would be good to document somewhere what the limits in the parser would be (roughly) with this change... >...

> Hey @finnbear i have a feeling that this might prevent actual complex objects from being parsed successfully. You're not wrong, there is *some* level of depth that wouldn't parse...

Note that SurrealDB stores UUIDs more efficiently than the string representation. There is a choice to be made about whether to do the same for ULIDs, or even to replace...

> Yep, but ULID are just a representational state of the UUID. It shouldn't pose any problem if it's binary equivalent. Alright, in that case, I'm guessing the UUID detection...

> If we can work out the exact **string** representation for a ULID It's (exactly) 26 characters in the base32 alphabet `0123456789ABCDEFGHJKMNPQRSTVWXYZ` with a maximum value of `7ZZZZZZZZZZZZZZZZZZZZZZZZZ` (to prevent...

> I humbly think that accepting only uppercase as ULID would make it a clear distinction between a string and an ULID, even in exchange of readability given by lowercase...

As a side note, query parse time is not reported in the time to execute a query. That could be good (for benchmarking query performance) or bad (for transparency).

Upon further investigation, I believe that one reason for the exponential time complexity is ambiguity when parsing expressions. When the parser is parsing a value, it can't disprove that `(((((5)))))`...