Open GoogleCodeExporter opened 8 years ago
Original comment by jules.te...@gmail.com
on 24 Feb 2015 at 9:00
Actually, this result is consistent with the statement that AQL does not
support comparison of complex values. Maybe this was the reason to have a
distinct operator separate from the group by in the first place?
Original comment by jules.te...@gmail.com
on 25 Feb 2015 at 12:59
Jules, your last comment is right in terms of only supporting scalar compares -
which means the bug is that the query doesn't get a runtime type error. This
makes me wonder if we have some remaining holes that didn't get plugged when
Taewoo was doing his heroic work on getting comparisons right everywhere. (In
addition to making sure the right scalar comparisons are made, we need to
error-out if the result is not scalar.)
Original comment by dtab...@gmail.com
on 25 Feb 2015 at 7:21
PS - On the grouping vs. distinct-ing front, we have both simply for usability
reasons. (Under the covers we should rewrite, as you know, distinct-ing into
grouping without formation of the groups' associated info.)
Original comment by dtab...@gmail.com
on 25 Feb 2015 at 7:22
Actually, right now, in my INT64 + Type Casting branch, as well as in master
branch, if two types are not comparable, we are just doing the byte-by-byte
comparison. Unordered list or record is this case. Thus, we do not want to
compare complex values such as unordered list, ordered list, and records?
Original comment by wangs...@gmail.com
on 25 Feb 2015 at 7:36
Original issue reported on code.google.com by
jules.te...@gmail.com
on 24 Feb 2015 at 9:00