Yes, and the Marklogic entry reminded me - the answer should probably be
modeled (for us) after XQuery - where the answers are fully spelled out
already (having been debated by a group of smart people first and
implemented by a bunch of XQuery engine providers):
http://www.w3.org/TR/xpath-functions-30/#func-substring-before
http://www.w3.org/TR/xpath-functions-30/#func-substring-after
Cheers,
Mike
On 9/28/15 6:10 PM, Taewoo Kim wrote:
Perhaps we can start from here:
https://docs.google.com/spreadsheets/d/1j6_YSCc_8gEReAWFP84geI30wlnsz7uMFq4TCm7GRz8/edit?usp=sharing
Best,
Taewoo
On Mon, Sep 28, 2015 at 6:05 PM, Mike Carey <[email protected]> wrote:
At times like this it's useful to take a quick look at what other systems
do, if they have such functions - e.g., are there precedents we should base
our answer on? (In Java, Postgres, MySQL, ...)
On 9/28/15 6:03 PM, Jianfeng Jia wrote:
Hi Devs,
Another question about the string functions.
The example code on the
http://asterixdb.ics.uci.edu/documentation/aql/functions.html#StringFunctions
<
http://asterixdb.ics.uci.edu/documentation/aql/functions.html#StringFunctions>
shows that these two function are suppose to be called after contains(). I
wonder what is the expected behavior if the they can't find the match
pattern?
The current result is confusing.
e.g.
let $x := "substring"
return [ substring-before($x, "subx"), substring-after($x, “subx”)]
it will return
[ [ "subst", "" ]
]
Should we always return an empty string in such case, or throw an
exception like “you shall filter the result by contain() first” ?
IMHO, I’d like to return a null string. Any opinion?
Best,
Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine
