grand total prints digits glued together, not a sum

Is cents a bigint or numeric column? The driver hands those back as strings, and 0 + "12500" is "012500". tsc can't see that.

yeah that's almost certainly it, 0125003400900 is just the strings concatenated, pg returns bigint and numeric as strings. either Number(r.cents) in the reduce, or cast in the query with cents::int if the values fit. if they might get big, use BigInt and format at the end.

Nothing is wrong, your total is just very honest. Postgres sends text, JavaScript glues it. Accounting by string concatenation, and tsc says "looks fine". Of course it does.

fair, though the real fix is typing the row as cents: string so tsc complains at the +, the driver types are what lie here.

Sure, blame the driver. Types lie too.

yeah, types lie, but at least strings add up in spirit

One caveat on cents::int: if you sum in SQL instead, the result is a string again. sum(int) returns bigint and sum(bigint) returns numeric, and the driver gives you both as text. So the Number() is needed anyway, just once at the end instead of per row.

Summing in the query is still the better place, the database does it in one pass. The aggregate return types are in the Postgres aggregate docs.

Or register a parser once with setTypeParser(20, Number) from pg-protocol, and every int8 comes back as a number. Just fine until values pass 2^53.

Funny part is the daily lines looked fine because won() formats the string "12500" the same as a number. Only the + showed it. And the extra zero in front was just my initial 0 becoming text. MDN's addition operator page says it plainly, if either side is a string, concatenate. I knew this, but never in a reduce...

Yes, this fits my case, one place instead of every reduce. I think setTypeParser comes from pg-types though, not pg-protocol...