Postgres in Rust neu geschrieben: besteht jetzt 100 % der Postgres-Regressionstests

 (github.com/malisper)
1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • pgrust ist ein Rewrite-Projekt in Rust mit dem Ziel der Kompatibilität zu Postgres 18.3 und liefert bei mehr als 46.000 Regressionsabfragen dieselben erwarteten Ausgaben wie Postgres
  • Es bietet Festplattenkompatibilität, sodass es aus einem bestehenden Postgres-18.3-Datenverzeichnis booten kann, und nutzt die echten Postgres-Tests als Verhaltensmaßstab
  • Derzeit ist es nicht produktionsreif, noch nicht performanceoptimiert, und bestehende Postgres-Erweiterungen sowie prozedurale Spracherweiterungen wie PL/Python, PL/Perl und PL/Tcl sind im Allgemeinen nicht kompatibel
  • Ausprobieren lässt es sich über eine WebAssembly-Demo und das Docker-Image malisper/pgrust:v0.1; latest verweist derzeit auf dasselbe Release, das fest gepinnte Laufzeit-Image ist jedoch v0.1
  • Die Roadmap umfasst multithreaded Postgres-Internals, integriertes Connection Pooling, Verbesserungen für JSON-zentrierte Workloads, Experimente mit No-Vacuum-Storage und Runtime-Guardrails für KI-generiertes SQL

Ziele und Kompatibilität von pgrust

  • pgrust ist ein Projekt, das Postgres in Rust neu schreibt
  • Zielversion ist Postgres 18.3; bei mehr als 46.000 Regressionsabfragen stimmen die Ausgaben mit den erwarteten Ausgaben von Postgres überein
  • Es bietet Festplattenkompatibilität, sodass es aus bestehenden Postgres-18.3-Datenverzeichnissen booten kann
  • Ziel des Projekts ist es, Postgres intern leichter veränderbar zu machen
    • Das Verhalten bleibt Postgres-artig
    • Echte Postgres-Tests werden als Referenz verwendet
    • Mit Rust und KI-gestützter Programmierung werden tiefgreifendere Serveränderungen erkundet

Aktueller Stand und Einschränkungen

  • pgrust ist noch nicht produktionsreif
  • Es wurde noch keine Performanceoptimierung vorgenommen
  • Bestehende Postgres-Erweiterungen und prozedurale Spracherweiterungen sind im Allgemeinen noch nicht kompatibel
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • Einige gebündelte contrib-Module wurden bereits portiert; mit der Zeit könnte mehr Kompatibilität möglich werden

Ausführung

  • Die WebAssembly-Demo kann unter https://pgrust.com ausprobiert werden
  • Für die Ausführung mit Docker wird das Image malisper/pgrust:v0.1 verwendet
    • Dabei wird der psql-Client innerhalb des Images genutzt
    • malisper/pgrust:latest verweist derzeit auf dasselbe Release
    • Das fest gepinnte Release-Image ist 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

Aus dem Quellcode bauen und ausführen

  • Unter macOS werden icu4c, openssl@3 und libpq benötigt
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"
  • Unter Debian/Ubuntu werden Build-Tools sowie ICU, OpenSSL, LDAP, PAM und der Postgres-18-Client installiert
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • Der Build erfolgt mit cargo build, wobei das vendored Shared-Verzeichnis von Postgres 18.3 angegeben wird
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • Das Datenverzeichnis wird mit --initdb von pgrust erstellt
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • Beim Start werden Stack-bezogene Einstellungen und synchrone I/O-Einstellungen gemeinsam verwendet
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

Regressionstests und Verifizierungsergebnisse

  • Die Postgres-Regressionstests werden mit scripts/run-regression ausgeführt
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • Der Test-Runner verwendet pgrusts eigenes --initdb und die im Repository enthaltenen Testdateien von Postgres 18.3
  • Im PATH muss der Postgres-18-Client psql vorhanden sein
    • Falls er an einem anderen Ort liegt, wird PGRUST_PSQL=/path/to/psql gesetzt
  • Das verifizierte Release-Ergebnis lautet, dass pgrust bei mehr als 46.000 Regressionsabfragen mit den erwarteten Ausgaben von Postgres übereinstimmte

Roadmap und Projekthistorie

  • Die Roadmap umfasst folgende Punkte

    • Multithreaded Postgres-Internals

      • Integriertes Connection Pooling
      • Verbesserte Unterstützung für JSON-zentrierte Workloads
      • Schnelle Fork- und Branching-Workflows
      • Storage-Experimente einschließlich No-Vacuum-Designs
      • Runtime-Guardrails für fehlerhafte Abfragen und KI-generiertes SQL
      • Verringerung plötzlicher Wechsel zu schlechten Ausführungsplänen
      • Das aktuelle Repository enthält eine neuere pgrust-Implementierung, die den Meilenstein der Regressionstests erreicht hat
      • Die frühere öffentliche Implementierung ist unter archive/pre-fabled-2026-06-23 archiviert
      • Links mit weiterem Hintergrund
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • Die Lizenz ist AGPL-3.0

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Meinungen auf Hacker News

  • Ich bin der ursprüngliche Autor. Ich hatte nicht erwartet, dass das hier auftaucht. Kurz gesagt: Ich habe an einem Experiment gearbeitet, mit LLMs ein besseres Postgres zu bauen, und da Postgres 30 Jahre alt ist, denke ich, dass wir in der Zwischenzeit viel über Datenbanken gelernt haben.
    Viele Techniken, die beim Neuschreiben nützlich sind, sind auch beim Neudesign hilfreich. Eine neue, noch nicht veröffentlichte Version von pgrust besteht derzeit 100 % der Postgres-Regressionstests, implementiert statt des Pro-Verbindung-ein-Prozess-Modells von Postgres ein Thread-pro-Verbindung-Modell, ist bei transaktionalen Workloads 50 % schneller als Postgres und bei analytischen Workloads etwa 300-mal schneller.
    Aktuell ist es in clickbench 2-mal langsamer als ClickHouse, aber ich glaube, dass es schneller als ClickHouse werden kann. Wenn es Fragen gibt, beantworte ich sie gern.

    • Thread pro Verbindung ist aus Performance-Sicht fast immer die richtige Wahl, aber weil Postgres sich für Prozess pro Verbindung entschieden hat, kann man beliebige fragwürdige Extensions laden. Im schlimmsten Fall stirbt nur dieser Prozess, nicht die gesamte Datenbank. Es wäre gut, einen Mittelweg zu haben, bei dem ein Segmentation Fault in einer Extension nicht alles, sondern nur einige Verbindungen beendet.
    • Eine Verbesserung um 50 % bei OLTP erscheint mir etwas verdächtig. Ich will das nicht unbegründet schlechtreden, und ich stelle selbst oft Benchmark-Behauptungen auf, aber obwohl ich sehe, dass ein Standard-Benchmark verwendet wurde, klingelt bei mir irgendetwas.
      Vielleicht wurde irgendwo MVCC gebrochen und ein Kompromiss eingegangen, der nicht produktionstauglich ist. Ich habe gesehen, dass die Regressionstests bestanden werden. Ist fsync vielleicht aktiviert? Soweit ich weiß, erfassen Regressionstests schlechte I/O-Muster nicht besonders gut. Trotzdem sieht es nach einem interessanten Projekt aus.
    • Mich interessiert der tatsächliche Hintergrund und die Expertise zu Postgres und Datenbanken allgemein. Letztlich möchte ich wissen, ob man genau weiß, was man tut, oder ob irgendwo eine riesige unbekannte Landmine lauert.
    • Es wirkt eher wie ein Experiment als wie ein Produkt-Launch, und jemand hat es unter den HN-Spotlight-Bus geschubst. Mich würde interessieren, ob das ein Experiment ist, um zu sehen, wie weit man mit LLM-Coding kommt, oder ob zuerst gebaut wurde und man dann schaut, wie viel vom von LLMs geschriebenen Code akzeptabel ist.
    • Dass es bei analytischen Workloads etwa 300-mal schneller als Postgres und 2-mal langsamer als ClickHouse ist, bedeutet das, dass die Daten in einem spaltenorientierten Format gespeichert werden? Oder werden sowohl zeilen- als auch spaltenorientierte Formate verwendet?
      Ich baue mit δx etwas Ähnliches, aber doch anderes. Es ist eine Postgres-Extension, die spaltenorientiert komprimierte Daten in normalen Postgres-Tabellen speichert, sodass Replikation, Disaster Recovery, pg_dump usw. unverändert funktionieren: https://github.com/xataio/deltax
      Derzeit ist es auf einem einzelnen Node 30–40 % langsamer als ClickHouse. Ein PR zur Aufnahme in clickbench wurde gerade angenommen, sodass man den Vergleich hier sehen kann: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • Solche Neuschreibungen verstehe ich nicht so recht. Meist werden sie von einer einzelnen Person vorangetrieben, was leicht zu einem Single Point of Failure wird, und sie entstehen in sehr kurzer Zeit, sodass kaum davon auszugehen ist, dass dabei die Disziplin zum langfristigen Aufbau eines Projekts gelernt wurde.
    Auch mittel- bis langfristig scheint die Wahrscheinlichkeit gering, dass es gepflegt wird. Wer beitragen will, muss ebenfalls Token-Kosten tragen. Denn es wird immer schwieriger, solche Projekte ohne KI zu warten. Würde jemand so etwas in Produktion einsetzen wollen? Ergibt für mich nicht viel Sinn.

    • Es ist nicht nur ein simples Neuschreiben, sondern es gibt auch Verbesserungen. Ich habe aus Spaß etwas Ähnliches gemacht, weil ich sehen wollte, ob man alte Designentscheidungen verbessern kann, insbesondere Stellen, bei denen die PostgreSQL-Leute sagten: „Das geht nicht anders.“ Tatsächlich geht es anders.
      In Produktion würde ich es nicht einsetzen, aber ich habe viel über Datenbank-Interna gelernt. Um auch im LLM-Zeitalter meinen Kopf zu beschäftigen, implementiere ich Datenbankfunktionen in unserer Produktionsdatenbank auch ohne LLMs. Derzeit kämpfe ich mit Flexible Paxos; wahrscheinlich bleiben wir beim alten, stabilen und einfachen Raft, aber interessant ist es trotzdem.
    • Ich sehe es als interessanten Proof of Concept. Es geht nicht nur darum, PostgreSQL in Rust neu zu schreiben, sondern auch darum, die gewählten Abhängigkeiten, die Änderung des Threading-Modells und mögliche andere Architekturänderungen zu testen.
      LLMs sind stark darin, Prototypen extrem schnell zu erstellen, und ein funktionierender Prototyp kann viele Spekulationen beenden. Ohne Unterstützung durch das ursprüngliche Team oder eine vergleichbar große Gruppe und ohne eine glaubwürdige Erklärung, dass Codequalität und Wartbarkeit des Originals erreicht oder übertroffen wurden, würde ich eine Neuschreibung eines so riesigen Projekts wohl nicht nutzen.
      Allgemein halte ich es rechtlich wie moralisch für schwer zu verteidigen, mit LLMs License Laundering zu betreiben. In diesem Fall ist es aber anders, weil eine restriktivere Lizenz gewählt wurde. Ich bin kein Anwalt, aber nach meinem Verständnis wäre es rechtlich möglich, PostgreSQL herunterzuladen, s/MIT/AGPL/ auszuführen und es dann zu verbreiten. Die ursprüngliche MIT-lizenzierte Version bleibt ja unverändert verfügbar, daher gibt es bis zu überzeugenden neuen Funktionen keinen Grund, diese Version zu bevorzugen.
    • Es ist nicht ganz dasselbe, aber ein 3D-Modell auf Basis vorhandener Zeichnungssätze neu zu erstellen ist viel schneller und einfacher, als es von Grund auf zu bauen. Viele Entscheidungen wurden nämlich bereits getroffen.
    • Bei einem Projekt von der Größe von Postgres ist Wartung ohne KI praktisch nahezu unmöglich. Wenn ich mich richtig erinnere, hat Postgres über eine Million Zeilen.

  • Die beste Methode, das zu testen, wäre wohl, einen Proxy wie PgBouncer vor eine stark ausgelastete Produktionsdatenbank zu setzen und die Queries gleichzeitig an das bestehende Postgres und an die Rust-Version zu spiegeln.
    So ließen sich Ausgabe und Performance unter realer Last vergleichen. Nach einiger Zeit könnte man auch die Tabellen einzeln mit einer normalen Postgres-Instanz vergleichen.

  • Wie sollte man solchen Code reviewen? Normalerweise überfliegt man die Commit-Historie und schaut, was Leute wie gemacht haben, aber wenn ein LLM in weniger als einem Monat 7101 Commits erzeugt, ist das unmöglich.
    Schon ein einziger Tag ist zu viel [1]. Abgesehen davon verrät der Inhalt der Commits möglicherweise ohnehin nicht besonders viel. Ich frage mich auch, ob es auf GitHub eine einfache Möglichkeit gibt, zum ersten Commit eines Repositorys zu springen. Das Durchsuchen der Commit-Historie fühlt sich ziemlich umständlich an.
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • Ich arbeite zusammen mit malisper an pgrust. Bei solchen Projekten wird sich der Fokus wohl eher darauf verlagern, Tests und Fuzzing-Prozesse zu prüfen, statt jeden einzelnen Commit zu reviewen.
      Man muss deutlich weiter gehen als die Regressions-, Isolations- und Fehlertests von Postgres. Dazu ein Artikel von danluu: https://danluu.com/ai-coding/
    • Die github cli hat einen Befehl, um Commits mit Flags für aufsteigende/absteigende Sortierung abzufragen: https://cli.github.com/manual/gh_search_commits
      Die Doku zu Syntax wie before x date findet sich hier: https://docs.github.com/en/search-github/searching-on-github...
      Es gibt auch eine Seite für erweiterte Suche, aber sie unterstützt keine Commits mit Datumsfilter: https://github.com/search/advanced
      Man kann im Such-Widget auch per binärer Suche nach dem Datum suchen; der erste Tag mit Commits ist hier: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      Erster Commit: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • Allgemein gesagt: Wenn es keine Prompt-Historie gibt und man die LLM-„Kompilierung“ nicht selbst erneut ausführen kann, ist unklar, ob das Open Source ist. Es fühlt sich eher wie ein „Source available“-Projekt an, bei dem man den Code lesen kann, aber keinen Zugriff auf das Build-System hat.
      Andererseits hatten wir, abgesehen von Commit-Messages, auch nie Zugriff auf die internen Denkprozesse menschlicher Entwickler; deshalb ist es vielleicht nicht ganz dasselbe, geheime Prompts als geschlossenen Source Code zu bezeichnen.
    • Um auf GitHub einfach zum ersten Commit zu gelangen, kann man die Syntax github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 verwenden. Wegen des neuesten Commits und des letzten Commits zieht man dabei gewissermaßen -1, -1 ab.
      Beispiel: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • Gar nicht reviewen. Man kann nur darauf vertrauen, dass bestandene Regressionstests bedeuten, dass es vollständig mit dem Original kompatibel ist.

  • Beeindruckend ist es schon, aber es ist eine Lizenzänderung von der PostgreSQL-Lizenz [0] zu AGPL [1].
    Ich mag die AGPL und halte sie für die beste der wirklich freien Open-Source-Lizenzen, aber ich mache mir Sorgen, ob das kompatibel ist. Wenn es aus dem Original-Source neu geschrieben wurde, müsste dann nicht die ursprüngliche Lizenz gelten? Ich denke schon. Es gab bereits einen Trend, Open-Source-Software unter restriktiveren Lizenzen neu zu schreiben, etwa wie Rusts coretools. Dass AGPL gewählt wurde, wirkt zwar deutlich ethischer, aber wäre es nicht sicherer gewesen, sie gar nicht zu ändern?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • Du scheinst die Richtung der Restriktivität umgekehrt verstanden zu haben. Die MIT-lizenzierten uutils coreutils sind weniger restriktiv als die GPL-lizenzierten GNU coreutils, und die AGPL ist restriktiver als die PostgreSQL-Lizenz.
      Eine Neufassung unter einer restriktiveren Lizenz zu veröffentlichen, verstößt nicht gegen die PostgreSQL-Lizenz. Der Grund, warum MIT-artige Lizenzen weniger restriktiv sind als GPL oder AGPL, ist genau der, dass sie eine restriktivere Neulizenzierung erlauben.
    • Wenn dir die Lizenz nicht gefällt, kannst du ein LLM ein paar Tage lang „portieren“ lassen und dann die gewünschte Lizenz dranhängen. Offenbar macht man das heutzutage so.
    • Die PostgreSQL-Lizenz ist eine BSD-Lizenzvariante und damit mit (A)GPL kompatibel.
      Man kann es so verstehen: Man erstellt ein leeres (A)GPL-Projekt und importiert die upstream BSD-Codebasis. Die ursprünglichen upstream Dateien bleiben unter ihrer ursprünglichen permissiven Lizenz, aber das Gesamtprojekt unterliegt der (A)GPL, einschließlich der Anforderungen der upstream Lizenz zur Urheber-/Copyright-Nennung. Die GPL erlaubt solche Anforderungen. Danach kann man eigenen Code unter AGPL hinzufügen und das kombinierte Werk unter AGPL verbreiten.
      Wenn jemand nur die von dir geschriebenen Teile deines Codes übernimmt, muss er nur die AGPL einhalten. Wenn jedoch auch der upstream Source enthalten ist, müssen weiterhin die Anforderungen der upstream Lizenz zur Urheber-/Copyright-Nennung erfüllt werden.
    • Die Postgres-Lizenz ist bereits vollständig mit der AGPL kompatibel. BSD/MIT sind permissiver.

  • Es gibt 2664 Vorkommen von unsafe { und 1835 von unsafe fn. Das ist überhaupt nicht sicher. Es sieht nicht nach einer Neufassung aus, bei der verstanden wurde, was tatsächlich passiert und wie man die Architektur neu entwerfen müsste, um die Vorteile von Rust zu nutzen.
    Stattdessen wirkt es wie eine KI-generierte Konvertierung mit extensiver Nutzung roher Pointer.

    • Der Großteil von unsafe steckt in dem Parser, der durch Anwendung von c2rust auf den Postgres-Parser erzeugt wurde. Der Postgres-Parser selbst wird ebenfalls aus yacc/bison generiert, daher hat man sich für eine mechanische Portierung entschieden, statt ihn in idiomatisches Rust zu übertragen.
      Wenn es besonders gravierende unsafe-Stellen gibt, wäre ein Hinweis hilfreich.
    • LLM-Projekte, die in Rust geschrieben werden, setze ich alle auf unsafe=deny. Ich verstehe nicht, warum nicht alle mit genau solchen Reaktionen rechnen.
    • Man könnte diesen Review-Kommentar einfach unverändert in den Prompt kopieren. Ein paar Stunden später heißt es dann vermutlich: „behoben!“

  • Ich glaube, man muss stark zwischen einer Neufassung und einer KI-Neufassung unterscheiden.

    • Zum Beispiel wurde die Go-Neufassung von TypeScript größtenteils von Menschen gemacht und hat ein Jahr bis zur Veröffentlichung gebraucht. So sehen Software-Neufassungen aus, denen Leute vertrauen können.
    • Ganz so einfach scheint es nicht zu sein. Ich glaube, nahezu 100 % neuer und ambitionierter Projekte werden in gewissem Umfang KI einsetzen. Ich kenne ein paar Projekte mit strikter No-AI-Policy, etwa Zig, aber das ist meiner Ansicht nach eine sehr kleine Minderheit.
      Ab welchem Umfang an KI-Nutzung wird es dann zu einer „KI-Neufassung“?
    • Neufassungen fühlen sich wie ein Bereich an, in dem LLMs besser passen als Menschen. Es ist größtenteils stumpfe Wiederholungsarbeit, und LLMs eignen sich gut für Übersetzungsaufgaben. Wenn ich mich richtig erinnere, wurde die Transformer-Architektur ursprünglich auch für Übersetzung erfunden.
    • Eine menschliche Neufassung ohne Wartung ist nur ein Hobbyprojekt. Bei einer KI-Neufassung frage ich mich, wofür man überhaupt Tokens verbrennt.
    • Inzwischen ist es einfach ein Build-Schritt geworden.

  • Ich sehe oft, dass solche Neufassungsprojekte behaupten, sie funktionierten, weil sie sich auf Tests stützen. Aber Software wie Postgres oder SQLite vertrauenswürdig macht weniger die Tests selbst als vielmehr die Narben aus dem Betrieb.
    Zuverlässigkeit entsteht über Jahre im produktiven Einsatz.

    • Der Großteil einer riesigen Testsuite sind genau diese Narben aus dem Betrieb. Denn jedes Mal, wenn ein Bug oder eine Regression auftritt, schreibt man einen Test, der das korrekte Verhalten überprüft.
      SQLite ist ein gutes Beispiel. Die gewaltigen nicht öffentlichen Tests von SQLite werden oft als Grund genannt, warum es schwer ist, SQLite zu forken. Turso hat es zwar geschafft, aber um vergleichbare Sorgfalt sicherzustellen, braucht es ein Unternehmen. Und natürlich auch Jahre im Betrieb.
    • Das ist kein Urteil über diese konkrete Neufassung, aber Tests sind die Spezifikation dafür, dass Software korrekt funktioniert. Wenn ein Verhalten durch keinerlei automatisierte Tests abgedeckt ist, kann man nicht behaupten, dass eine bestimmte Änderung dieses Verhalten nicht bricht.
      Es ist völlig vernünftig zu sagen, dass etwas funktioniert, wenn es die bestehende, unveränderte Testsuite besteht. Je größer das Projekt, desto mehr gilt das meiner Ansicht nach. Die im Betrieb gesammelten Narben müssen in der Testsuite dokumentiert und geschützt werden, sonst gehen diese Lektionen verloren.
      SQLite ist für seine riesige Testsuite und umfassendes Fuzzing bekannt. Es hat 590-mal mehr Testcode und Skripte als regulären Code. Quelle: https://sqlite.org/testing.html
    • Dann sollte man diese Zuverlässigkeit leicht upstream zurückfließen lassen können.
      Das Nützlichste, was man mit so einer LLM-Konvertierung derzeit tun kann, ist: Wenn die konvertierte Version alle ursprünglichen Tests besteht, lasse ich die Testsuite meiner Anwendung darauf laufen, um Lücken in der Testabdeckung des Originals zu finden.
      Wenn die konvertierte Version abstürzt oder ein beobachtbares Fehlverhalten zeigt, bedeutet das, dass dem eigentlichen Projekt ein Regressionstest fehlte. Wenn man solche Konvertierungsprojekte sicher und einfach als eine Zeile in der alltäglichen Integrationstest-Matrix laufen lassen könnte, ließe sich viel besser verhindern, dass Upstream bei künftigen Updates versehentlich etwas kaputtmacht.
    • Stimme zu. Ich stimme auch dem Nebenkommentar zu, dass man jedes Mal, wenn ein Bug oder eine Regression auftritt, einen Test schreibt, der das korrekte Verhalten überprüft.
      Was ich bei solchen Neufassungen allerdings nicht sehe, ist die Frage, was mit den Bugs passiert, die durch die Neufassung neu eingeführt wurden. Müssen sie sich am Ende nicht selbst in realen Szenarien bewähren?
    • Es gibt auch andere Möglichkeiten, eine Neufassung zu validieren. Man kann einfach pgrust und postgres parallel ausführen und die Ausgaben vergleichen.
      Wenn man Edge Cases kennt, lässt man auch die laufen; wenn nicht, sucht man mit einem Fuzzer oder automatisierten Tools nach interessanten Eingaben. Findet man eine Abweichung, wird dieses Eingabe-/Ausgabe-Paar zum Testfall. Ich weiß nicht, ob es so ein Tool gibt, aber falls ja, könnte man es Claude geben und in die Entwicklungsschleife einbauen lassen.

  • Die WebAssembly-Demo, die im Browser läuft, ist wirklich sauber gemacht: https://pgrust.com

  • Ich verstehe nicht, warum hier so viel Negativität herrscht. Solche Projekte finde ich zu Lernzwecken und zur Erkundung neuer Ansätze interessant. Was ist daran das Problem?

    • Vielleicht liegt es daran: Man hängt sich an etablierte Markennamen wie Postgres + Rust, hat aber keinen praktischen Nutzen oder Fortschritt vorzuweisen und es fehlt an Vertrauenswürdigkeit.
      Vor allem wenn im Titel ein starkes Signalwort wie Postgres steht und damit geworben wird, es aber aus Gründen wie kurz- und langfristiger Praxistauglichkeit, gesellschaftlichem Vertrauen und Netzwerkeffekten offensichtlich unpraktisch ist, entsteht wohl leicht Ablehnung.
    • Es ist unangenehm zu sehen, wie Jahrzehnte an Arbeit so leicht kopiert werden können.
    • Ich frage mich, was man genau lernt, wenn man ein LLM eine Neufassung erstellen lässt.
    • Die Leute fühlen sich offenbar bedroht, wenn sie sehen, dass ein LLM Aufgaben gut erledigt, für die sie ihre eigenen Fähigkeiten und Talente für nötig hielten.
      Das ist nachvollziehbar, aber weder produktiv noch besonders rational als negative Emotion. Dieser Thread ist voll von Beiträgen, die argumentieren wollen, dass das unmöglich gut sein kann, nicht gut sein darf und am Ende ganz sicher in einer Katastrophe endet. Doch die Tatsache, dass dieses Ding Zehntausende ausgefeilter Tests bestanden hat, die über Jahrzehnte entstanden sind, deutet auf das Gegenteil hin. Das ist schwer zu widerlegen.
      Natürlich ist die Wahrscheinlichkeit hoch, dass neue Probleme entstehen, aber trotzdem ist es eine beeindruckende Leistung.
    • Ich mache mir Sorgen um die Qualität. Schon ein flüchtiger Blick über den Code lässt ihn dumm wirken. Es sei denn, ich erkenne die geniale Seite des Codes einfach nicht.
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...