On Sat, Jan 18, 2014 at 6:15 PM, David Rowley <dgrowle...@gmail.com> wrote:
> On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug <f...@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: https://github.com/david-rowley/postgres/commit/43a5021e8f8ae1af272e7e21a842d1b0d5cbe577 Regards David Rowley
