Re: Prevent printing "next step instructions" in initdb and pg_upgrade

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Дата
Msg-id CABUevEwmczP6v3HYtf=Gapd1V9snoX8q3Gc3QOszoP11jHBHtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Список 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 по дате отправления:

Предыдущее
От: gkokolatos@pm.me
Дата:
Сообщение: Re: Strange behavior with polygon and NaN
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Rethinking LOCK TABLE's behavior on views