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 CABUevEy1Vf7aHOfUM+3fAW=is+sGGzL2BufPai6eRayEy=FkSg@mail.gmail.com
Whole thread Raw
In response to Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Responses Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Mon, Nov 9, 2020 at 2:18 PM Anastasia Lubennikova
<a.lubennikova@postgrespro.ru> wrote:
>
> On 02.11.2020 16:23, Magnus Hagander wrote:
>
> On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
>
> On 2020-10-06 12:26, Magnus Hagander wrote:
>
> I went with the name --no-instructions to have the same name for both
> initdb and pg_upgrade. The downside is that "no-instructions" also
> causes the scripts not to be written in pg_upgrade, which arguably is a
> different thing. We could go with "--no-instructions" and
> "--no-scripts", but that would leave the parameters different. I also
> considered "--no-next-step", but that one didn't quite have the right
> ring to me. I'm happy for other suggestions on the parameter names.
>
> What scripts are left after we remove the analyze script, as discussed in a
> different thread?
>
> There is still delete_old_cluster.sh.
>
> I wonder if we should just not do it and just say "you should delete
> the old cluster". Then we can leave it up to platform integrations to
> enhance that, based on their platform knowledge (such as for example
> knowing if the platform runs systemd or not). That would leave us with
> both pg_upgrade and initdb printing instructions, and not scripts, and
> solve that part of the issue.
>
> Do we only care about .sh scripts? There are also reindex_hash.sql and pg_largeobject.sql in
src/bin/pg_upgrade/version.cwith instructions.
 
> How should we handle them?

Oh, that's a good point. I had completely forgotten about those.

For consistency, one might say that those should be dropped as well.

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?

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



pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Next
From: John Naylor
Date:
Subject: Re: document pg_settings view doesn't display custom options