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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
