On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug <fgp@phlo.org> wrote:
* Don't we need to check for volatile function in the filter expression too?
I did manual testing on this before and the volatility test for the aggregate arguments seems to cover this. I didn't look into why but it just did. I've not test this again since your refactoring. I could test this easily before when my numeric case was changing the results because of the dscale problem, I noticed that if I did FILTER(WHERE random() > 0) that the extra trailing zeros would disappear.
The problem now is that it's pretty hard to determine if an inverse transition took place, the only way we can really tell is performance. I'll see if I can invent a new test case for this by creating a user defined aggregate as you described. I'm thinking just append '+' to a string for transitions and '-' to a string for inverse transitions, then just make sure we only have a string of '+'s when doing something like filter(where random() >= 0).
I've added a test case for this and it seem work as expected:
