Строки по дням в порядке (12500, 3400, 900 won), а вот TOTAL выводит 0125003400900 KRW. Откуда лишний ноль?
const grand = rows.reduce((acc, r) => acc + r.cents, 0);
console.log(`TOTAL ${won(grand)}`);tsc проходит, Postgres 16 в docker. Тот же reduce, что и всегда...
Daily lines are fine (12500, 3400, 900 won), but TOTAL prints 0125003400900 KRW. Why extra zero?
const grand = rows.reduce((acc, r) => acc + r.cents, 0);
console.log(`TOTAL ${won(grand)}`);tsc passes, Postgres 16 in docker. Same reduce as always...
cents у вас bigint или numeric? Драйвер возвращает такие колонки строками, а 0 + "12500" это "012500". tsc этого не видит.
Is cents a bigint or numeric column? The driver hands those back as strings, and 0 + "12500" is "012500". tsc can't see that.
да, почти наверняка дело в этом, 0125003400900 это просто склеенные строки, pg отдаёт bigint и numeric строками. Либо Number(r.cents) в reduce, либо приведение в запросе через cents::int, если значения влезают. Если могут быть большие, используйте BigInt и форматируйте в самом конце.
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.
Всё в порядке, ваш итог просто очень честный. Postgres присылает текст, JavaScript его склеивает. Бухгалтерия через конкатенацию строк, а tsc говорит «выглядит нормально». Ещё бы.
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.
справедливо, но реальный фикс — типизировать строку как cents: string, чтобы tsc ругнулся на +, врут тут типы драйвера.
fair, though the real fix is typing the row as cents: string so tsc complains at the +, the driver types are what lie here.
Конечно, вините драйвер. Типы тоже врут.
да, типы врут, зато строки хотя бы складываются по духу
Одна оговорка насчёт cents::int: если суммировать в SQL, результат снова будет строкой. sum(int) возвращает bigint, а sum(bigint) возвращает numeric, и драйвер отдаёт оба как текст. Так что Number() всё равно нужен, только один раз в конце, а не на каждую строку.
Суммировать в запросе всё равно лучше, база делает это за один проход. Типы возвращаемых значений агрегатов описаны в документации Postgres по агрегатам.
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.
Или один раз зарегистрировать парсер через setTypeParser(20, Number) из pg-protocol, и каждый int8 будет приходить числом. Нормально, пока значения не превысят 2^53.
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.
Забавно, что строки по дням выглядели нормально, потому что won() форматирует строку "12500" так же, как число. Только + всё выдал. А лишний ноль спереди это просто мой начальный 0, ставший текстом. На странице MDN про оператор сложения всё прямо сказано: если хотя бы одна сторона строка, происходит конкатенация. Я это знал, но не в reduce...
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...
Да, это подходит для моего случая, одно место вместо каждого reduce. Хотя мне кажется, setTypeParser из pg-types, а не из pg-protocol...
Yes, this fits my case, one place instead of every reduce. I think setTypeParser comes from pg-types though, not pg-protocol...
Маленькая утилита на database/sql вернула половину списка. Без ошибки. Код такой. Контекст с дедлайном. Дедлайн истёк посреди…
Пишу небольшой job runner на Go для учебного проекта. Стек: pgx v5 через database/sql, локально Postgres 16, таблица jobs при…
Очередь задач прямо в таблице. Один воркер на Python, второй на Go. BEGIN, потом SELECT id, payload FROM jobs WHERE status =…
