On Wed, Oct 6, 2021 at 09:56:34AM -0700, Jeremy Schneider wrote: > On 10/5/21 17:43, Bruce Momjian wrote: > > On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote: > >> Specifically exposing pg_waldump functionality in SQL could speed up > >> finding bugs in the PG logical replication code. We found and fixed a > >> few over this past year, but there are more lurking out there. > > > > Uh, why is pg_waldump more important than other command line tool > > information? > > Going down the list of all other utilities in src/bin: > > * pg_amcheck, pg_config, pg_controldata: already available in SQL > * psql, pgbench, pg_dump: already available as client-side apps > * initdb, pg_archivecleanup, pg_basebackup, pg_checksums, pg_ctl, > pg_resetwal, pg_rewind, pg_upgrade, pg_verifybackup: can't think of any > possible use case outside server OS access, most of these are too low > level and don't even make sense in SQL > * pg_test_fsync, pg_test_timing: marginally interesting ideas in SQL, > don't feel any deep interest myself > > Speaking selfishly, there are a few reasons I would be specifically > interested in pg_waldump (the only remaining one on the list).
This is the analysis I was looking for to understand if copying the features of command-line tools in extensions was a wise direction. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
