Re: pg_upgrade defaulting to port 25432

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade defaulting to port 25432
Date: 2011-06-25 02:22:55
Message-ID: BANLkTi=Ar3ye24m47jHe1mdft_2ZMsNd2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Peter Eisentraut wrote:
>> On fre, 2011-06-24 at 16:34 -0400, Bruce Momjian wrote:
>> > > > It also creates two new environment variables,
>> > > > OLDPGPORT and NEWPGPORT, to control the port values because we
>> > don't
>> > > > want to default to PGPORT anymore.
>> > >
>> > > I would prefer that all PostgreSQL-related environment variables
>> > start
>> > > with "PG".
>> >
>> > OK, attached.  I was also using environment variables for PGDATA and
>> > PGBIN do I renamed those too to begin with 'PG'.
>>
>> I'm wondering why pg_upgrade needs environment variables at all.  It's a
>> one-shot operation.  Environment variables are typically used to shared
>> default settings across programs.  I don't see how that applies here.
>
> They were there in the original EnterpriseDB code, and in some cases
> like PGPORT, we _used_ those environment variables.  Also, the
> command-line can get pretty long so we actually illustrate environment
> variable use in its --help:
>
>        For example:
>          pg_upgrade -d oldCluster/data -D newCluster/data -b oldCluster/bin -B newCluster/bin
>        or
>          $ export OLDDATADIR=oldCluster/data
>          $ export NEWDATADIR=newCluster/data
>          $ export OLDBINDIR=oldCluster/bin
>          $ export NEWBINDIR=newCluster/bin
>          $ pg_upgrade
>
> You want the environment variable support removed?

I don't. It's production usefulness is questionable, but it's quite
handy for testing IMO.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2011-06-25 06:15:05 Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Previous Message Robert Haas 2011-06-25 02:22:16 Re: Deriving release notes from git commit messages