Re: Explicit psqlrc
От | Robert Haas |
---|---|
Тема | Re: Explicit psqlrc |
Дата | |
Msg-id | AANLkTim68f_Q_f2geksy5TXOP=UnrJ6rcx7DschfKp75@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Explicit psqlrc (David Christensen <david@endpoint.com>) |
Ответы |
Re: Explicit psqlrc
Re: Explicit psqlrc |
Список | 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 по дате отправления: