Re: Prevent printing "next step instructions" in initdb and pg_upgrade - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Date
Msg-id 20201109142856.GA3956@alvherre.pgsql
Whole thread Raw
In response to Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Magnus Hagander <magnus@hagander.net>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Reduce the number of special cases to build contrib modules on windows
Next
From: John Naylor
Date:
Subject: Re: WIP: BRIN multi-range indexes