Explicit psqlrc
in [PgSql]
|
Prev: [PATCH] elimination of code duplication in DefineOpFamily()
Next: [HACKERS] trace_recovery_messages
From: Robert Haas on 20 Jul 2010 11:48 On Tue, Jul 20, 2010 at 11:23 AM, David Christensen <david(a)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 running scripts 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 to explicitly 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mark Wong on 20 Jul 2010 12:08 On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote: >> >>> Since it has been over a month since this review was posted and no new >>> version of the patch has appeared, I think we should mark this patch >>> as Returned with Feedback. >> >> Mark posted a new patch 6 days ago, AFAICS. > > Hmm. �I can't find it in my mail, in my archives, or linked off the > CommitFest application. �Was it posted under a different subject line? > �Do you have a link to the archives? My bad, I didn't want to appear to hijack the patch from David. I have added the link to the commitfest app, and I'll give it here: http://archives.postgresql.org/message-id/AANLkTikFpzrTRl6392GhatQdwlCWQTXFdSMxh5CP51iv(a)mail.gmail.com Regads, Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 20 Jul 2010 12:31 On Tue, Jul 20, 2010 at 12:08 PM, Mark Wong <markwkm(a)gmail.com> wrote: > On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >>> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote: >>> >>>> Since it has been over a month since this review was posted and no new >>>> version of the patch has appeared, I think we should mark this patch >>>> as Returned with Feedback. >>> >>> Mark posted a new patch 6 days ago, AFAICS. >> >> Hmm. �I can't find it in my mail, in my archives, or linked off the >> CommitFest application. �Was it posted under a different subject line? >> �Do you have a link to the archives? > > My bad, I didn't want to appear to hijack the patch from David. �I > have added the link to the commitfest app, and I'll give it here: > > http://archives.postgresql.org/message-id/AANLkTikFpzrTRl6392GhatQdwlCWQTXFdSMxh5CP51iv(a)mail.gmail.com Oh, cool, I missed that, obviously. So I guess we need someone to review that version, then. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 20 Jul 2010 15:18 Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010: > > 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 I think we should just make sure -X works, and have .psqlrc be read when it's not specified regardless of -f and -c switches. Otherwise it's just plain confusing. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Christensen on 20 Jul 2010 15:36
On Jul 20, 2010, at 2:18 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010: > >>> 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 > > I think we should just make sure -X works, and have .psqlrc be read when > it's not specified regardless of -f and -c switches. > > Otherwise it's just plain confusing. +1. Regards, David -- David Christensen End Point Corporation david(a)endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |