On Mon, Oct 13, 2025 at 9:19 PM David Barsky <[email protected]> wrote: > > SQLite is fantastic, but it's type-system and lock-model are too > > restrictive, > > for a general DB. Similar to David, I think PostgreSQL is close to my ideal > > above, yet still far-enough (and perhaps unwilling enough, as a community) > > to venture into embedded and localhost use-cases, that it's frustrating. > > Yup, Dominique understands what I want: Postgres' type system, query planner, > and locking model, but _shades_ of SQLite's operational properties during > local > development. However, I don't really need Postgres to function like an > embedded > database; I just want the self-contained process cleanup. Connecting to > Postgres > over TCP over localhost is perfect for my use-case
Except postgres is actively hostile to localhost testing by not supporting ephemeral TCP ports... Why oh why??? My own servers are unit tested that way. Why would postgres.exe prevent the use of port 0? Any work-around that picks a "free" port is racy and ugly. There's a clean idiom for that, and that's port 0. Why disable it? I don't get it... --DD D:\pdgm\trunk\psc2\pgdata>where postgres.exe D:\pdgm\kits\trunk\postgresql\17.6\Win_x64_10_v17\bin\postgres.exe D:\pdgm\trunk\psc2\pgdata>where initdb.exe D:\pdgm\kits\trunk\postgresql\17.6\Win_x64_10_v17\bin\initdb.exe D:\pdgm\trunk\psc2\pgdata>initdb -D .\test1 -U postgres -A trust The files belonging to this database system will be owned by user "ddevienne". ... Success. You can now start the database server using: pg_ctl -D ^"^.^\test1^" -l logfile start D:\pdgm\trunk\psc2\pgdata>postgres -D .\test1 -p 0 2025-10-15 09:43:59.293 GMT [42288] FATAL: 0 is outside the valid range for parameter "port" (1 .. 65535)
