I believe that is a static optimization: the query processor knows that
the xs:dateTime() expression is static, cheap to process, and has no
side-effects, so it evaluates at parse time rather than run time.
Arguably this particular case is buggy, but would you really write the
query that way? I'd bind the candidate values, either directly or as a
function call parameter.
let $i := "1999-01-01TTT0:0:0"
return
if ($i castable as xs:dateTime) then xs:dateTime($i) else ()
Or, in a more XQuery-like idiom:
let $i := "1999-01-01TTT0:0:0"
where $i castable as xs:dateTime
return xs:dateTime($i)
Those both work fine for me, with 4.1-1 and 1.0-ml.
-- Mike
On 2009-09-04 09:52, David Sewell wrote:
I don't know if "bug" is the right term, but certainly "limitation".
This is still the case in ML 4.1-1.
And this workaround is not even possible:
if ("1999-01-01TTT0:0:0" castable as xs:dateTime)
then xs:dateTime("1999-01-01TTT0:0:0")
else ()
It still throws an XDMP-CAST error, meaning the "then" result is being
evaluated in a static context and not optimized away. (In eXist and
Saxon XQuery, by contrast, the query succeeds.)
So I think you'd have to go with a workaround like
let $date := "1999-01-01TTT0:0:0"
let $castable := $date castable as xs:dateTime
return
if ($castable)
then xs:dateTime($date)
else ()
On Fri, 4 Sep 2009, Paul M wrote:
Not sure if bug, need workaround ideas regardless..
3.2-10
let $x := try{xs:dateTime("1999-01-01TTT0:0:0")} catch($ex) {()}
let $y := try{ 2 div 0 } catch($ex) {()}
return $x
Return a dateTime if possible. Otherwise, return empty sequence.
The second try-catch works. The first does not.
What would you do if you knew one of your casts may fail? My only idea is
regexp?
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
