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