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

From Magnus Hagander
Subject Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Date
Msg-id CABUevEwmczP6v3HYtf=Gapd1V9snoX8q3Gc3QOszoP11jHBHtA@mail.gmail.com
Whole thread Raw
In response to Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Prevent printing "next step instructions" in initdb and pg_upgrade
List pgsql-hackers
On Mon, Nov 9, 2020 at 3:29 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> 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

What would be the actual use-case in this though?

I can see the --suppress-scripts=delete_old_cluster, but that's
basically the only usecase I can see for this. And for use in any
wrapper, that wrapper would have to know ahead of time what the
options would be... And if that's the only usecase, than this ends up
basically boiling down to the same as my suggestion just with a more
complex switch? :)

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: gkokolatos@pm.me
Date:
Subject: Re: Strange behavior with polygon and NaN
Next
From: Alvaro Herrera
Date:
Subject: Re: Rethinking LOCK TABLE's behavior on views