Re: pg_upgrade -u - Mailing list pgsql-general

From Bruce Momjian
Subject Re: pg_upgrade -u
Date
Msg-id 20130529151724.GA32690@momjian.us
Whole thread Raw
In response to Re: pg_upgrade -u  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-general
On Wed, May 29, 2013 at 09:42:12AM -0400, Peter Eisentraut wrote:
> On 5/21/13 2:41 PM, Bruce Momjian wrote:
> > I have thought about this and there are potentially several options
> > specified to pg_upgrade that could be passed into scripts:
> >
> >   -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 "root")
> >
> > However, if we pass these items into the scripts, we then force these
> > values to be used, even if the user wants to use a different value.  It
> > is a balance between supplying defaults vs. requiring the user to supply
> > or change the values used during the ugprade.
> >
> > At this point, I have favored _not_ supplying defaults in the script.
> > Do you have an alternative argument in favor of supplying defaults?
>
> You could put environment variable assignments at the top of the script,
> so they are easy to change or remove.  But it seems to me the values
> should be in there somehow.

Yes, that was another option, though I am worried that I am going to
start getting script-specific, no?  Can I just do this:

    PGUSER="postgres"
    export PGUSER

    vacuumedb -U "$PGUSER"

Is that portable?  I know I can't do:

    export PGUSER="postgres"

as older shells can't process that.  What about -P?  Do I pass that too?
I now realize we can't pass -O.

This is all easy to do for 9.4 if we can just agree on it.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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


pgsql-general by date:

Previous
From: Thom Brown
Date:
Subject: Re: Foreign Key violated
Next
From: Vick Khera
Date:
Subject: Re: foreign key to multiple tables depending on another column's value