Re: Explicit psqlrc - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Explicit psqlrc
Date
Msg-id AANLkTim68f_Q_f2geksy5TXOP=UnrJ6rcx7DschfKp75@mail.gmail.com
Whole thread Raw
In response to Re: Explicit psqlrc  (David Christensen <david@endpoint.com>)
Responses Re: Explicit psqlrc
Re: Explicit psqlrc
List pgsql-hackers
On Tue, Jul 20, 2010 at 11:23 AM, David Christensen <david@endpoint.com> wrote:
>> Well, IIRC, one of -c and -f suppresses psqlrc, and the other does
>> not.  This doesn't seem very consistent to me, but I'm not sure
>> there's much to be done about it at this point.  I guess if you use
>> whichever one suppresses psqlrc even once, it's suppressed, and
>> otherwise it's not.  :-(
>
> That seems sub-optimal; I can see people wanting to use this feature to do something like:
>
> psql -c 'set work_mem = blah' -f script.sql
>
> and then being surprised when it works differently than just `psql -f script.sql`.

I agree... but then they might also be surprised if psql -c
'something' works differently from psql -c 'something' -f /dev/null

> Although I wonder if the general usecase for .psqlrc is just in interactive mode; i.e., hypothetically if you're
runningscripts that are sensitive to environment, you're running with -X anyway; so maybe that's not that big of a
deal,as it's kind of an implied -X with multiple -c or -f commands.  And if you really wanted it, we could add a flag
toexplicitly include .psqlrc (or the user could just specify -f path/to/psqlrc). 

It's tempting to propose making .psqlrc apply only in interactive
mode, period.  But that would be an incompatibility with previous
releases, and I'm not sure it's the behavior we want, either.

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


pgsql-hackers by date:

Previous
From: Etienne Dube
Date:
Subject: Re: [PATCH] "could not reattach to shared memory" on Windows
Next
From: Robert Haas
Date:
Subject: Re: Query optimization problem