Bug in extractStateIntervals

[tnixon]

It turns out that there's a bug in extractStateIntervals such that comparisons are not applied across all metrics, but only until the first one evaluates as "true".

Example:

event_ts	user	device	x	y	z
2015-02-24T13:30:49.232+0000	b	s3_2	-0.96725750	0.03830722	9.14585
2015-02-24T13:30:49.242+0000	b	s3_2	-0.93852705	-0.22026655	8.81066

When compared with the ">=" operator the records above come out as belonging to the same "state", which implies that the operator should be true for each pair of metrics in current >= previous, so:

• -0.93852705 >= -0.96725750 (true - the first is a "smaller" negative number, so greater than the second)
• -0.22026655 >= 0.03830722 (false)
• 8.81066 >= 9.14585 (false)

It appears that the problem stems from comparing values in an array, like so:

select
  array(-0.93852705, -0.22026655, 8.81066) >= 
  array(-0.96725750,  0.03830722, 9.14585)

It appears that the SQL engine compares the elements in the array until it finds a true value, then it short-cut returns true for the entire comparison. It appears that this is a lexicographical comparison, in which the first non-same element will determine the results. For more detailed comparison, try this:

select
  (a >= b),
  zipped,
  transform(zipped, x -> x["a"] >= x["b"] ),
  forall( zipped, x -> x["a"] >= x["b"] )
from
  ( select
      a,
      b,
      arrays_zip(a, b) as zipped
    from
      ( select
          array(-0.93852705, -0.22026655, 8.81066) as a, 
          array(-0.96725750,  0.03830722, 9.14585) as b ) )

We need to compare all metrics with the given comparison operation independently, and then return the conjunction (logical AND) of the results.