Re: Prevent printing "next step instructions" in initdb and pg_upgrade
От | Alvaro Herrera |
---|---|
Тема | Re: Prevent printing "next step instructions" in initdb and pg_upgrade |
Дата | |
Msg-id | 20201109142856.GA3956@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Prevent printing "next step instructions" in initdb and pg_upgrade (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Prevent printing "next step instructions" in initdb and pg_upgrade
|
Список | pgsql-hackers |
On 2020-Nov-09, Magnus Hagander wrote: > But for usability that makes less sense. For the delete script, the > wrapper (that the switch is intended for) knows more than pg_upgrade > about how to delete it, so it can do a better job, and thus it makes > sense to silence it. But for something like these .sql (and also in > the previously mentioned case of extension upgrades), pg_upgrade knows > more and the only thing the wrapper could do is to reimplement the > same functionality, and maintain it. > > I wonder if the best way forward might be to revert it back to being a > --no-instructions switch, remove the delete_old_cluster.sh script > completely and just replace it with instructions saying "you should > delete the old cluster", and then keep generating these scripts as > necessary? How about a switch like "--with-scripts=<list>" where the list can be "all" to include everything (default), "none" to include nothing, or a comma-separated list of things to include? (Also "--with-scripts=help" to query which things are supported) So "--with-scripts=reindex_hash,largeobject" omits the useless delete_old_cluster script and keeps the ones you want. Perhaps you could see it in the negative direction as more convenient, so --suppress-scripts=delete_old_cluster
В списке pgsql-hackers по дате отправления: