Re: New 'pg' consolidated metacommand patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: New 'pg' consolidated metacommand patch
Date
Msg-id CA+TgmoYUwD6R6qL0aEg5gCWQ1BAB_rpeYJw8jH9uQu4eukLteA@mail.gmail.com
Whole thread Raw
In response to Re: New 'pg' consolidated metacommand patch  (Magnus Hagander <magnus@hagander.net>)
Responses Re: New 'pg' consolidated metacommand patch
List pgsql-hackers
On Wed, May 27, 2020 at 4:51 AM Magnus Hagander <magnus@hagander.net> wrote:
>> For that reason, I did not change the names of the executables, merely their location.  During conversations with
Robertoff-list, we discussed renaming the executables to things like 'pg-ctl' (hyphen rather than underscore), mostly
becausethat's the more modern way of doing it and follows what 'git' does.  To avoid breaking scripts that execute
thesecommands by the old name, this patch doesn't go that far.  It also leaves the usage() functions alone such that
whenthey report their own progname in the usage text, they do so under the old name.  This would need to change at some
point,but I'm unclear on whether that would be for v14 or if it would be delayed. 
>
> Ugh, yeah, please don't do that. Renaming them just to make it "look more modern" helps nobody, really. Especially if
thesuggestion is people should be using the shared-launcher binary anyway. 

The way things like 'git' work is that 'git thunk' just looks in a
designated directory for an executable called git-thunk, and invokes
it if it's found. If you want to invent your own git subcommand, you
can. I guess 'git help' wouldn't know to list it, but you can still
get the metacommand to execute it. That only works if you use a
standard naming, though. If the meta-executable has to hard-code the
names of all the individual executables that it calls, then you can't
really make that work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: BufFileRead() error signalling
Next
From: Alvaro Herrera
Date:
Subject: Re: segmentation fault using currtid and partitioned tables