Re: pg_utility ?

From: Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Christoph Berg <myon(at)debian(dot)org>
Subject: Re: pg_utility ?
Date: 2025-11-18 19:49:02
Message-ID: CAC8Q8tJMXrnDqL=Vufw6pKfX5SMLA9F+sPhO-MHbe1Pv09y-Og@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 5, 2025 at 4:29 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> I didn't immediately love this idea, but I'm not totally opposed to it
> either, and perhaps it makes things better rather than adding yet
> another very narrowly-focused tool. Also, pg_ctl already kinda has a
> somewhat similar facet with its "pg_ctl init" mode.
>

I support this idea, moving these scattered commands under pg_ctl will
definitely help and bring maintenance commands in line with other
ecosystems where it's normal to follow the template of "[ecosystem]
[action] [arguments]".
Examples:
- docker run postgres
- pip install h3
- apt install postgres
- systemctl status postgresql
- pg_ctl start

In this pattern stuff like vacuumdb, createuser, createlang, createdb, ...
looks very off.

The same migration recently happened in imagemagick/graphicsmagick, where
instead of the old "convert" binary there is now "gm convert" that better
controls expectations (you won't attempt to convert to mp3 with it).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-11-18 19:56:22 Re: [PATCH] Allow complex data for GUC extra.
Previous Message Tomas Vondra 2025-11-18 19:37:40 Re: Performance issues with parallelism and LIMIT