Peter Eisentraut wrote:
> In the above case, you create a bunch of traps. If the user abandons
> the attempt to run pg_upgrade but leaves the shell open, comes back at
> some other time (or, say, someone else who also logs into the shared
> postgres account), and runs just "pg_upgrade" for lack of a better idea
> or forgets an option, a destructive operation might start. Yes, they
> are stupid and it's their fault and there are other ways to break
> things, but pg_upgrade is already tricky enough, we don't need to add
> more hidden ways to break it.
>
> (Besides, the above isn't even a portable way to set environment
> variables. You need to run the assignment and the export separately.)
True.
> > You want the environment variable support removed?
>
> Well, it might be difficult to get consensus on that. I would argue
> that we don't need to add new ones for a marginal operation like the
> pg_upgrade check mode.
Well, hard to make any changes without consensus. None of these
variables are check-mode only.
> On the other hand, a way to permanently override the new upgrade port
> you are working on might be useful. It's not clear from the patch how
> to do that, actually.
That's because the flags to control the port numbers were already there;
I only changed pg_upgrade to use new environment variables and changed
their defaults to 50234, and no longer use PGPORT so I don't import the
runtime port number. I think that is why it seems unclear.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
