Comment 25 for bug 1174498

The loop structure requires that either the payments or the billings are in the outer loop or the inner loop. Payments are on the outer loop, figuring that there are fewer payment rows than billing rows, because people tend to make lump payments. This is issue:

IF billing_remainder >= payment_remainder THEN
....
ELSE
current_result.amount = billing_remainder;
...
END IF

Which, unfortunately is repeated code in different contexts. (I contemplated making another function with that logic that we could call, instead of repeating the lines but I liked that this function was self-contained). The execution falls into the ELSE block and assigns "amount" a 0.0 value because billing_remainder is 0.0 and there are still some greater-than-zero payments we're trying to match. Classic negative balance. I agree, that the loops should exit when we're at the end of the billing rows and billing_remainder is 0.0. I had a choice to either test for that OR introduce the 0.0 guard. I chose the 0.0 guard because it was more full proof. We don't want to write a row with $0 money for any reason (and this is one way we could end up here, but there could be others). I felt that was more solid logic than testing for the single scenario.

Thanks for working on pgTap tests! A much-needed addition. Make this function work for it!