On Wed, May 29, 2013 at 08:59:42AM -0400, Ray Stell wrote: > > [ moved to hacker ] > > > > Wow, I never realized other tools used -U for user, instead of -u. > > Should I change pg_upgrade to use -U for 9.4? I can keep supporting > > -u as an undocumented option. > > That would make for consistency, but not change the broken behavior. > Comments on this below. > > > > I have applied the attached patch to document that you might need to > > set connection parameters for vacuumdb. > > That will work as this is not a big deal, but have to admit, I didn't > understand the logic you posted in your question. If the src cluster > has a alternate superuser (from initdb -U), and the the pg_upgrade > command has to be supplied a -u/-U in order to work with the src > cluster, why would you assume somehow the output cluster has changed > to the default superuser when you build the vacuum script on the > other side of pg_upgrade? Is that even possible to accomplish? Your > statement about "forcing the values" throws me, as it seems to me the > user is requesting the variation. I have not dug into pg_upgrade's > guts, so I may just be uninformed.
OK, so let's look again at what you can supply to pg_upgrade for new cluster connections: -O, --new-options=OPTIONS new cluster options to pass to the server -P, --new-port=NEWPORT new cluster port number (default 50432) -u, --user=NAME cluster superuser (default "postgres") So, probably all of these _could_ be propagated to created scripts, like analyze_new_cluster.sh. However, if we do that, we hardwire these values into the script, meaning you can't override them with environment variables like PGUSER. The question is whether hard-wiring these helps more than it hurts, and which ones should be hard-wired. One new idea would be to add "$@" to the vacuumdb script parameters so users could supply their own "-U myuser" options to the script. That is easy to do for Unix, which I assume all support "$@", but perhaps hard for Windows. -- 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
