Postgres를 Rust로 재작성, 이제 Postgres 회귀 테스트 100% 통과

 (github.com/malisper)
1P by GN⁺ | ★ favorite | 댓글 1개
  • pgrust는 Postgres 18.3 호환을 목표로 하는 Rust 재작성 프로젝트이며, 46,000개 이상의 회귀 쿼리에서 Postgres의 예상 출력과 일치함
  • 기존 Postgres 18.3 데이터 디렉터리에서 부팅할 수 있는 디스크 호환성을 갖추고, 실제 Postgres 테스트를 동작 기준으로 삼음
  • 현재는 프로덕션 준비 상태가 아니며 성능 최적화도 아직 되어 있지 않고, 기존 Postgres 확장과 PL/Python·PL/Perl·PL/Tcl 같은 절차 언어 확장은 일반적으로 호환되지 않음
  • WebAssembly 데모와 Docker 이미지 malisper/pgrust:v0.1로 실행해볼 수 있으며, latest는 현재 같은 릴리스를 가리키지만 고정 실행 이미지는 v0.1임
  • 로드맵은 멀티스레드 Postgres 내부 구조, 내장 연결 풀링, JSON 중심 워크로드 개선, no-vacuum 저장소 실험, AI 생성 SQL을 위한 런타임 가드레일을 포함함

pgrust의 목표와 호환성

  • pgrust는 Postgres를 Rust로 재작성하는 프로젝트임
  • 목표 대상은 Postgres 18.3이며, 46,000개 이상의 회귀 쿼리에서 Postgres의 예상 출력과 일치함
  • 기존 Postgres 18.3 데이터 디렉터리에서 부팅할 수 있는 디스크 호환성을 제공함
  • 프로젝트의 목표는 내부에서 Postgres를 더 쉽게 바꿀 수 있게 만드는 것임
    • 동작은 Postgres 형태로 유지함
    • 실제 Postgres 테스트를 기준으로 사용함
    • Rust와 AI 보조 프로그래밍으로 더 깊은 서버 변경을 탐색함

현재 상태와 제한

  • pgrust는 아직 프로덕션 준비 상태가 아님
  • 아직 성능 최적화가 되어 있지 않음
  • 기존 Postgres 확장과 절차 언어 확장은 일반적으로 아직 호환되지 않음
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • 일부 번들 contrib 모듈은 이미 포팅됐으며, 시간이 지나며 더 많은 호환성이 가능할 수 있음

실행 방법

  • WebAssembly 데모는 https://pgrust.com 에서 실행해볼 수 있음
  • Docker 실행은 malisper/pgrust:v0.1 이미지를 사용함
    • 이미지 내부의 psql 클라이언트를 사용함
    • malisper/pgrust:latest는 현재 같은 릴리스를 가리킴
    • 고정된 출시 이미지는 v0.1임
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1 && until docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres; docker rm -f pgrust

소스 빌드와 실행

  • macOS에서는 icu4c, openssl@3, libpq가 필요함
brew install icu4c openssl@3 libpq

export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"
  • Debian/Ubuntu에서는 빌드 도구와 ICU, OpenSSL, LDAP, PAM, Postgres 18 클라이언트를 설치함
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • 빌드는 vendored Postgres 18.3 공유 디렉터리를 지정해 cargo build로 수행함
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • 데이터 디렉터리는 pgrust의 --initdb로 생성함
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • 실행 시 스택 관련 설정과 동기 I/O 설정을 함께 사용함
ulimit -s 65520

RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

회귀 테스트와 검증 결과

  • Postgres 회귀 테스트는 scripts/run-regression으로 실행함
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • 테스트 러너는 pgrust의 자체 --initdb와 저장소에 포함된 Postgres 18.3 테스트 파일을 사용함
  • PATH에 Postgres 18 psql 클라이언트가 필요함
    • 다른 위치에 있으면 PGRUST_PSQL=/path/to/psql을 설정함
  • 검증된 출시 결과는 pgrust가 46,000개 이상의 회귀 쿼리에서 Postgres의 예상 출력과 일치했다는 것임

로드맵과 프로젝트 이력

  • 로드맵에는 다음 항목이 포함됨

    • 멀티스레드 Postgres 내부 구조

      • 내장 연결 풀링
      • JSON 중심 워크로드 지원 개선
      • 빠른 포크와 브랜칭 워크플로
      • no-vacuum 설계를 포함한 저장소 실험
      • 잘못된 쿼리와 AI 생성 SQL을 위한 런타임 가드레일
      • 갑작스러운 나쁜 실행 계획 전환 감소
      • 현재 저장소에는 회귀 테스트 이정표에 도달한 더 새로운 pgrust 구현이 들어 있음
      • 이전 공개 구현은 archive/pre-fabled-2026-06-23에 보관됨
      • 관련 배경 링크
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • 라이선스는 AGPL-3.0임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 원저자임. 여기 올라올 줄은 몰랐음. 요약하면 LLM으로 더 나은 Postgres를 만들어보는 실험을 해왔고, Postgres는 30년 된 만큼 그동안 데이터베이스에 대해 배운 것도 많다고 봄
    재작성에 유용한 기법 상당수는 재설계에도 유용함. 아직 공개하지 않은 새 pgrust 버전은 현재 Postgres 회귀 테스트를 100% 통과하고, Postgres의 프로세스당 연결 모델 대신 연결당 스레드 모델을 구현했으며, 트랜잭션 작업부하에서는 Postgres보다 50% 빠르고 분석 작업부하에서는 약 300배 빠름
    지금은 clickbench에서 ClickHouse보다 2배 느리지만, ClickHouse보다 더 빨라질 수 있다고 생각함. 질문 있으면 답하겠음

    • 연결당 스레드는 성능 관점에서 거의 항상 맞는 선택이지만, Postgres가 연결당 프로세스를 택한 덕분에 수상한 확장을 마음대로 로드할 수 있음. 최악의 경우 데이터베이스 전체가 아니라 해당 프로세스만 죽음. 확장에서 세그멘테이션 오류가 나도 전체가 아니라 일부 연결만 죽는 균형점이 있으면 좋겠음
    • OLTP에서 50% 개선은 좀 의심스러움. 근거 없이 몰아가고 싶진 않고 나도 벤치마크 주장을 자주 하지만, 표준 벤치마크를 썼다는 건 알면서도 뭔가 촉이 울림
      어딘가에서 MVCC를 깨서 운영에는 못 들어갈 절충을 했을 수도 있음. 회귀 테스트를 통과한다는 건 봤음. 혹시 fsync는 켜져 있나? 회귀 테스트는 나쁜 입출력 패턴을 잘 잡지 못하는 걸로 앎. 그래도 재미있는 프로젝트처럼 보임
    • Postgres와 데이터베이스 전반에 대한 실제 배경과 전문성이 궁금함. 결국 무슨 일을 하는지 정확히 알고 있는지, 아니면 모르는 거대한 발목 지뢰가 숨어 있는지 알고 싶음
    • 제품 출시라기보다 실험 중이었는데 누군가 HN 스포트라이트 버스 밑으로 밀어 넣은 것처럼 보임. 이게 LLM 코딩으로 어디까지 가능한지 보는 실험인지, 아니면 먼저 만들고 LLM이 작성한 코드 중 얼마나 받아들일 수 있는지 보는 실험인지 궁금함
    • 분석 작업부하에서 Postgres보다 약 300배 빠르고 ClickHouse보다 2배 느리다는 건 데이터를 열 지향 형식으로 저장한다는 뜻인가? 아니면 행 지향과 열 지향을 둘 다 쓰는 건가?
      비슷하면서도 다른 작업으로 δx를 만들고 있음. 일반 Postgres 테이블 안에 열 지향 압축 데이터를 저장하는 Postgres 확장이라 복제, 장애 복구, pg_dump 등이 그대로 동작함: https://github.com/xataio/deltax
      현재 단일 노드 기준 ClickHouse보다 30~40% 느림. clickbench에 추가하는 PR이 막 받아들여져서 여기서 비교를 볼 수 있음: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • 이런 재작성은 잘 이해가 안 됨. 보통 한 사람이 주도하는데 단일 장애점이 되기 쉽고, 아주 짧은 시간에 만들어져서 프로젝트를 꾸준히 만드는 규율을 익혔다고 보기 어려움
    중장기적으로 유지할 가능성도 낮아 보임. 기여하려는 사람도 토큰 비용을 내야 함. AI 없이 이런 프로젝트를 유지하기가 점점 어려워지기 때문임. 이런 걸 운영에 넣고 싶은 사람이 있을까? 별로 말이 안 됨

    • 단순한 재작성만은 아니고 개선도 있음. 재미로 비슷한 일을 해봤는데, 오래된 설계와 특히 PostgreSQL 쪽 사람들이 “다르게 할 수 없다”고 했던 부분을 개선할 수 있는지 보고 싶었음. 실제로 다르게 할 수 있음
      운영에 넣지는 않겠지만 데이터베이스 내부를 많이 배웠음. LLM 시대에도 머리를 즐겁게 하려고, 우리 운영 데이터베이스에도 LLM 없이 데이터베이스 기능을 구현함. 지금은 Flexible Paxos로 고생 중인데, 아마 오래되고 안정적이고 단순한 Raft를 계속 쓰겠지만 그래도 흥미로움
    • 흥미로운 개념 증명으로 봄. Rust로 PostgreSQL을 재작성하는 것뿐 아니라 선택한 의존성, 스레딩 모델 변경, 다른 아키텍처 변경의 가능성을 테스트하는 셈임
      LLM은 프로토타입을 엄청 빠르게 뽑아내는 데 강하고, 동작하는 프로토타입은 많은 추측을 끝낼 수 있음. 원래 팀이나 그에 준하는 상당한 인원이 뒷받침하지 않고, 원본 코드 품질과 유지보수를 맞췄거나 넘었다는 믿을 만한 설명이 없다면 이런 거대한 프로젝트의 재작성판은 쓰지 않을 것 같음
      일반적으로 LLM으로 라이선스 세탁을 하는 건 법적으로나 도덕적으로 방어하기 어렵다고 봄. 다만 이 경우는 더 제한적인 라이선스를 골랐다는 점에서 다름. 변호사는 아니지만 PostgreSQL을 내려받아 s/MIT/AGPL/ 한 뒤 배포하는 건 법적으로 가능하다고 이해함. 원래 MIT 라이선스 버전은 그대로 있으니, 설득력 있는 새 기능이 나오기 전까지는 굳이 그 버전을 선호할 이유가 없음
    • 완전히 같지는 않지만, 기존 도면 세트를 바탕으로 3D 모델을 다시 만드는 것은 처음부터 만드는 것보다 훨씬 빠르고 쉬움. 이미 많은 결정이 내려져 있기 때문임
    • Postgres 규모의 프로젝트에서는 AI 없이 유지하는 게 사실상 불가능에 가까움. 기억이 맞다면 Postgres는 100만 줄 이상임

  • 이걸 테스트하는 가장 좋은 방법은 바쁜 운영 데이터베이스 앞에 PgBouncer 같은 프록시를 두고, 쿼리를 기존 Postgres와 Rust 버전에 동시에 미러링하는 것 같음
    그러면 실제 부하에서 출력과 성능을 비교할 수 있음. 한동안 돌린 뒤 일반 Postgres 인스턴스와 테이블을 하나씩 비교해도 됨

  • 이런 코드는 어떻게 검토해야 할까? 보통은 커밋 이력을 훑어보며 사람들이 무엇을 어떻게 작업했는지 보는데, LLM이 한 달도 안 돼 7101개 커밋을 만들면 불가능함
    하루치만 봐도 너무 많음 [1]. 어차피 커밋 내용도 별로 많은 걸 알려주지 않을 수 있음. GitHub에서 저장소의 첫 커밋으로 쉽게 가는 방법도 궁금함. 커밋 이력 탐색은 꽤 번거롭게 느껴짐
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • pgrust에서 malisper와 같이 작업 중임. 이런 프로젝트에서는 각 커밋을 검토하기보다 테스트와 퍼징 과정을 검토하는 쪽으로 초점이 옮겨갈 것 같음
      Postgres의 회귀, 격리, 장애 테스트보다 훨씬 더 나아가야 함. 관련 danluu 글: https://danluu.com/ai-coding/
    • github cli에는 정렬 오름차순/내림차순 플래그로 커밋을 질의하는 명령이 있음: https://cli.github.com/manual/gh_search_commits
      before x date 같은 문법 문서는 여기 있음: https://docs.github.com/en/search-github/searching-on-github...
      고급 검색 페이지도 있지만 날짜 필터로 커밋은 지원하지 않음: https://github.com/search/advanced
      검색 위젯에서 날짜를 이분 탐색할 수도 있고, 커밋이 있는 첫날은 여기임: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      첫 커밋: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • 일반론으로, 프롬프트 이력이 없고 LLM “컴파일”을 직접 다시 실행할 수 없다면 이게 오픈소스인지 애매함. 코드는 읽을 수 있지만 빌드 시스템에는 접근할 수 없는 “소스 공개” 프로젝트에 더 가까운 느낌도 듦
      반대로 커밋 메시지를 제외하면 인간 개발자의 내부 사고 과정에도 접근한 적은 없었으니, 비밀 프롬프트가 곧 비공개 소스라고 말하기도 완전히 같지는 않을 수 있음
    • GitHub에서 첫 커밋으로 쉽게 가려면 github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 문법을 쓸 수 있음. 최신 커밋과 마지막 커밋 때문에 -1, -1을 하는 식임
      예: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • 검토하지 않음. 회귀 테스트 통과가 원본과 완전히 호환된다는 뜻이라고 믿는 수밖에 없음

  • 인상적이긴 하지만 PostgreSQL 라이선스 [0]에서 AGPL [1]로 바뀐 라이선스 변경임
    AGPL을 좋아하고 진정한 자유 오픈소스 라이선스 중 최고라고 생각하지만, 호환되는지 걱정됨. 원본 소스에서 재작성했다면 원본 라이선스가 적용되어야 하지 않나? 그렇다고 봄. Rust의 coretools처럼 오픈소스 소프트웨어를 더 제한적인 라이선스로 재작성하는 흐름이 있었음. AGPL을 골랐다는 점에서 훨씬 윤리적으로 보이긴 하지만, 아예 변경하지 않는 편이 더 안전하지 않았을까?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • 제한성 방향을 반대로 이해한 듯함. MIT 라이선스인 uutils coreutils는 GPL인 GNU coreutils보다 덜 제한적이고, AGPL은 PostgreSQL 라이선스보다 더 제한적임
      재작성판을 더 제한적인 라이선스로 배포해도 PostgreSQL 라이선스를 위반하지 않음. MIT 계열 라이선스가 GPL이나 AGPL보다 덜 제한적인 이유가 바로 더 제한적인 재라이선싱을 허용하기 때문임
    • 라이선스가 마음에 안 들면 LLM에게 며칠 동안 “포팅”하게 한 뒤 원하는 라이선스를 붙이면 됨. 요즘은 apparently 그렇게 하는 듯함
    • PostgreSQL 라이선스는 BSD 라이선스 변형이라 (A)GPL과 호환됨
      이렇게 이해하면 됨. 빈 (A)GPL 프로젝트를 만들고 업스트림 BSD 코드베이스를 가져옴. 원본 업스트림 파일은 원래의 허용적 라이선스 아래 남지만, 프로젝트 전체는 업스트림 라이선스의 저작자 표시 요구를 포함해 (A)GPL의 지배를 받음. GPL은 그런 요구를 허용함. 그 뒤 자기 코드를 AGPL로 추가하고 결합 저작물을 AGPL로 배포할 수 있음
      누군가 당신 코드 중 당신이 작성한 부분만 가져가면 AGPL만 따르면 됨. 하지만 업스트림 소스까지 포함하면 업스트림 라이선스의 저작자 표시 요구도 계속 충족해야 함
    • Postgres 라이선스는 이미 AGPL과 완전히 호환됨. BSD/MIT가 더 허용적임

  • unsafe {가 2664개, unsafe fn이 1835개임. 이건 완전히 안전하지 않음. 실제로 무슨 일이 벌어지는지, Rust의 장점을 살리려면 아키텍처를 어떻게 재설계해야 하는지 이해한 재작성처럼 보이지 않음
    대신 원시 포인터를 광범위하게 쓰는 AI 생성 변환처럼 보임

    • 대부분의 unsafe는 Postgres 파서에 c2rust를 돌려 생성한 파서 안에 갇혀 있음. Postgres 파서 자체도 yacc/bison에서 생성되므로, 관용적인 Rust로 옮기기보다 기계적으로 포팅하기로 했음
      특히 심각하다고 보는 unsafe가 있으면 알려주면 좋겠음
    • Rust로 작성하는 LLM 프로젝트는 전부 unsafe=deny로 설정함. 왜 모두가 이런 반응을 예상하지 않는지 모르겠음
    • 이 검토 코멘트를 프롬프트에 그대로 복사해 넣으면 되겠음. 몇 시간 뒤에는 “수정됨!”이 될 듯함

  • 재작성과 AI 재작성은 강하게 구분해야 할 것 같음

    • 예를 들어 TypeScript의 Go 재작성은 대부분 인간이 했고, 공개되기까지 1년이 걸렸음. 사람들이 신뢰할 수 있는 소프트웨어 재작성은 그런 방식임
    • 그렇게 단순하진 않은 듯함. 새롭고 야심 찬 프로젝트 거의 100%가 어느 정도는 AI를 활용하게 될 것 같음. Zig처럼 엄격한 무AI 정책을 가진 몇몇 프로젝트를 알지만, 아주 작은 소수라고 봄
      그렇다면 AI 사용량이 어느 정도여야 “AI 재작성”이 되는 걸까?
    • 재작성은 LLM이 인간보다 더 잘 맞는 영역처럼 느껴짐. 대부분 단순 반복 작업이고, LLM은 번역 작업에 잘 맞음. 기억이 맞다면 트랜스포머 아키텍처도 원래 번역을 위해 발명됐음
    • 유지보수 없는 인간 재작성은 취미 프로젝트일 뿐임. AI 재작성은 대체 뭘 위해 토큰을 태우는 건지 모르겠음
    • 이제는 그냥 빌드 단계가 된 셈임

  • 이런 재작성 프로젝트들이 테스트에 의존해서 동작한다고 주장하는 경우가 많이 보임. 하지만 Postgres나 SQLite 같은 소프트웨어를 신뢰할 수 있게 만드는 건 테스트 자체보다 운영 환경에서 쌓인 상처에 가까움
    신뢰성은 수년간 운영에서 돌아가며 쌓임

    • 방대한 테스트 스위트 대부분이 바로 운영의 상처임. 버그나 회귀가 생길 때마다 올바른 동작을 확인하는 테스트를 작성하기 때문임
      SQLite는 좋은 예임. SQLite의 방대한 비공개 테스트는 사람들이 포크하기 어렵게 만드는 요소로 자주 인용됨. Turso가 해내긴 했지만, 동등한 성실성을 보장하려면 회사가 필요함. 물론 수년간의 운영도 필요함
    • 이 특정 재작성에 대한 판단은 아니지만, 테스트는 소프트웨어가 올바르게 동작한다는 명세임. 어떤 동작이 자동화 테스트로든 덮여 있지 않다면, 특정 변경이 그 동작을 깨뜨리지 않는다고 주장할 수 없음
      기존의 수정되지 않은 테스트 스위트를 사용해 무언가가 동작한다고 말하는 건 완전히 합리적임. 프로젝트가 클수록 더 그렇다고 봄. 운영에서 얻은 상처는 테스트 스위트에 문서화되고 보호되어야 하며, 그렇지 않으면 그 교훈은 사라짐
      SQLite는 거대한 테스트 스위트와 광범위한 퍼징으로 유명함. 일반 코드보다 테스트 코드와 스크립트가 590배 많음. 출처: https://sqlite.org/testing.html
    • 그렇다면 그 신뢰성을 업스트림에 되돌리기 쉽게 만들어야 함
      지금 이런 LLM 변환판으로 할 수 있는 가장 유용한 일은, 변환판이 원본 테스트를 모두 통과한다면 내 애플리케이션 테스트 스위트를 그 위에서 돌려서 원본의 테스트 커버리지 부족을 찾아내는 것임
      변환판이 충돌하거나 관찰 가능한 오동작을 하면, 실제 프로젝트에 어떤 회귀 테스트가 빠져 있었다는 뜻임. 이런 변환 프로젝트를 일상적인 통합 테스트 매트릭스의 한 줄로 안전하고 쉽게 실행할 수 있다면, 업스트림이 향후 업데이트에서 실수로 무언가를 깨뜨리는 일을 훨씬 더 잘 막을 수 있음
    • 동의함. 버그나 회귀가 생길 때마다 올바른 동작을 확인하는 테스트를 작성한다는 옆 댓글에도 동의함
      다만 이런 재작성에서 보이지 않는 건, 재작성 때문에 새로 도입된 버그는 어떻게 하느냐는 부분임. 결국 자체적으로 현실 세계의 시나리오에서 도전을 겪어야 하지 않나?
    • 재작성을 검증하는 다른 방법도 있음. 그냥 pgrust와 postgres를 같이 실행하고 출력을 비교하면 됨
      엣지 케이스를 알고 있으면 그것도 돌리면 되고, 모르면 퍼저나 자동화 도구로 흥미로운 입력을 찾으면 됨. 불일치를 찾으면 그 입력/출력 쌍이 이제 테스트 케이스가 됨. 그런 도구가 있는지는 모르겠지만, 있다면 Claude에게 줘서 개발 루프에 넣게 하면 됨

  • 브라우저에서 실행되는 WebAssembly 데모가 정말 깔끔함: https://pgrust.com

  • 왜 이렇게 부정적인지 모르겠음. 이런 프로젝트는 학습 목적과 새로운 방식 탐색에 흥미롭다고 봄. 그게 뭐가 문제인가?

    • 아마도 이유는 이럴 수 있음. Postgres + Rust라는 확립된 브랜드명에 올라타고, 실용성이나 진전은 없으며, 신뢰도 부족함
      특히 제목에 Postgres 같은 신호가 강한 이름이 들어가고 그걸 내세우는데, 단기·장기 실용성, 사회적 신뢰, 네트워크 효과 같은 이유로 명백히 비실용적이면 쉽게 반감이 생기는 듯함
    • 수십 년의 작업이 이렇게 쉽게 복사되는 걸 보는 건 불편함
    • LLM에게 재작성을 시키는 것에서 정확히 무엇을 배우는지 궁금함
    • 사람들이 자기 기술과 재능이 필요하다고 여긴 일을 LLM이 잘 해내는 걸 보고 위협을 느끼는 듯함
      이해는 되지만 생산적이지도, 아주 합리적이지도 않은 부정적 감정임. 이 스레드에는 이게 좋을 리 없고, 좋아서도 안 되고, 결국 파국으로 끝날 게 분명하다고 주장하려는 글이 가득함. 그런데 이 물건이 수십 년간 축적된 수만 개의 정교한 테스트를 통과했다는 사실은 그 반대를 시사함. 반박하기 어려움
      물론 새 문제가 생길 가능성은 높지만, 그래도 인상적인 성취임
    • 품질이 걱정됨. 코드를 대충 훑어봐도 멍청해 보임. 코드의 천재적인 면을 내가 못 알아보는 게 아니라면
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
답변달기