Re: New 'pg' consolidated metacommand patch
От | Robert Haas |
---|---|
Тема | Re: New 'pg' consolidated metacommand patch |
Дата | |
Msg-id | CA+TgmoYUwD6R6qL0aEg5gCWQ1BAB_rpeYJw8jH9uQu4eukLteA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New 'pg' consolidated metacommand patch (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: New 'pg' consolidated metacommand patch
|
Список | 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 по дате отправления: