| 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).
| 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 |