문자열로 온 count(*)와 121건

손으로 적은 CountRow가 진짜 버그예요. 어느 방법을 고르든 그대로 남는 버그고요. pool.query<CountRow>는 문법만 예쁜 단언이에요. total이 숫자인지 확인한 건 아무것도 없고, 제네릭은 컴파일러한테 그렇게 믿으라고 했을 뿐이에요.

개수라면 캐스팅도 괜찮아요. count(*)::int는 20억을 조금 넘으면 범위 초과 에러로 시끄럽게 실패하는데, 할 일 목록이 거기까지 갈 일은 없어요. 다만 이건 이 열 하나만 고쳐요. 다음 bigint 열은 또 문자열로 오고, 타입은 또 아니라고 말할 거예요. 경계에 작은 파서를 두면 둘 다 막을 수 있어요.

function toCount(value: unknown): number {
  if (typeof value !== 'string' || !/^\d+$/.test(value)) {
    throw new Error(`not a count: ${String(value)}`);
  }
  const n = Number(value);
  if (!Number.isSafeInteger(n)) {
    throw new Error(`count too large: ${value}`);
  }
  return n;
}

행을 이걸로 한 번 통과시키고, 돌려받은 값으로 CountRow를 만들어요. 지금 같은 초기 단계라면 저는 일단 SQL에서 캐스팅하고, 두 번째 쿼리가 필요해질 때 파서를 넣겠어요.

두 방법 옆에 놓아 볼 셋째 선택지가 있습니다. bigint로 파싱해서 그대로 두는 것입니다. 그러면 TypeScript가 산술에서 bigint와 number를 섞는 것을 거부하므로 total + 1은 컴파일되지 않고, total + 1n이라고 써야 합니다. 화면에 필요했던 오류가 바로 그것입니다. 비용은 나머지 모든 곳에 있습니다. 서식 지정, 일반 숫자와의 엄격한 비교, JSON으로 넘어가는 모든 것에 변환이 필요합니다. 안전한 정수 범위를 벗어날 일이 없는 개수라면 number가 더 싼 표현이고, 그 결정은 tess.p가 올린 파서에서 내리는 것이 맞습니다.

tess.p 말대로 일단 SQL에서 count(*)::int로 캐스팅했어요. 헤더가 13건으로 제대로 올라가요. 그런데 같은 화면 아래쪽에 예상 비용 합계가 있거든요. sum(price)인데 price가 numeric이라 이것도 문자열로 와요. 지금은 화면에 그대로 찍히기만 해서 아무도 몰랐던 거예요. 할 일을 추가할 때 여기도 미리 더해 주려고 parseFloat를 붙이려다 손이 멈췄어요. 돈인데 이래도 되나요?

안 됩니다. 드라이버가 numeric을 문자열로 넘기는 이유가 바로 그 값이 십진수이고 이진 부동소수점은 그렇지 않기 때문입니다. parseFloat('19.99')부터가 이미 근삿값이고, 그런 값을 몇 개 더하면 합계 끝에 긴 자릿수가 붙어 나오거나 마지막 센트에서 반올림이 어긋납니다. 데이터베이스가 그 합을 정확하게 계산했으니 표시에는 문자열을 그대로 쓰십시오. 서버 응답 전에 화면에서 더해야 한다면 먼저 정수 센트로 바꿔 정수끼리 더하고, 서버 값이 도착하면 그것으로 바꾸십시오. 돈을 담은 열은 자릿수가 선언된 곳에서 더하는 것이 맞습니다.

JSON 쪽은 생각보다 빨리 문제가 돼요. JSON.stringify는 bigint를 만나면 TypeError를 던져요. 그래서 그 합계가 처음으로 응답 본문이나 저장된 상태에 들어가는 순간 런타임에서 실패하고, 컴파일러는 끝까지 아무 말도 안 해요. BigInt.prototype에 toJSON을 달 수는 있지만, 그러면 받는 쪽에 맞든 안 맞든 프로그램의 모든 bigint가 같은 방식으로 직렬화돼요. 여기서는 number가 맞다는 데 동의해요. 변환은 값이 나가는 곳마다가 아니라 파서에 있어야 하고요.

알겠어요, parseFloat는 뺐어요. 센트로 바꿔서 더하는 것까지 해 보려다가, 할 일 하나 추가할 때 비용을 미리 올려 주는 기능이 굳이 필요한가 싶어서 접었어요. 비용 합계는 이제 서버 응답이 오면 그때 바뀌고, 그 사이 반 초쯤은 이전 값이 보여요. (반 초 동안 틀린 숫자를 보는 것보다는 나아요.) 숫자를 미리 올리는 건 개수에만 남겼어요.

타입 문제에서 살짝 옆길로 새는 얘기예요. 낙관적인 total + 1은 개수를 읽은 뒤로 아무도 할 일을 넣지 않았다고 가정해요. 추가 요청이 새 개수를 돌려주게 하면 그 추측이 잠시 뒤 진짜 숫자로 바뀌어요.