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  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to