Explicit psqlrc
in [PgSql]
|
Prev: [PATCH] elimination of code duplication in DefineOpFamily()
Next: [HACKERS] trace_recovery_messages
From: Alvaro Herrera on 21 Jul 2010 13:31 Excerpts from Peter Eisentraut's message of mié jul 21 10:24:26 -0400 2010: > On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote: > > 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. > > What is a use case for having .psqlrc be read in noninteractive use? Even if there weren't one, why does it get applied to -f but not -c? They're both noninteractive. -- 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 21 Jul 2010 23:06 On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote: > Excerpts from Peter Eisentraut's message of mi� jul 21 10:24:26 -0400 2010: >> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote: >>> 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. >> >> What is a use case for having .psqlrc be read in noninteractive use? > > Even if there weren't one, why does it get applied to -f but not -c? > They're both noninteractive. So not to let the thread drop, it appears that we're faced with the following situation: 1) The current behavior is inconsistent with the psqlrc handling of -c and -f. 2) The current behavior is still historical and we presumably want to maintain it. I'm not sure of the cases where we're willing to break backwards compatibility, but I do know that it's not done lightly. So perhaps for this specific patch, we'd need/want to punt supporting both -c's in conjunction with -f's, at least until we can resolve some of the ambiguities in what the actual behavior should be in each of these cases. This could still be a followup patch for 9.1, if we get these issues resolved. And as long as we're redesigning the bike shed, I think a better use case for supporting multiple sql files would be to support them in such a way that you wouldn't need to provide explicit -f flags for each. Many programs utilize the '--' token for an "end of options" flag, with the rest of the arguments then becoming something special, such as filenames. So what about adding the interpretation that anything after '--' is interpreted as a filename? That will allow the use of shell wildcards to specify multiple files, and thus allow something like: $ psql -U myuser mydatabase -- *.sql $ psql -- {pre-,,post-}migration.sql while still being unambiguous with the current convention of having an unspecified argument be interpreted as a database name. This would make it possible to actually specify/use multiple files in a fashion that people are used to doing, as opposed to having to explicitly type things out or do contortions will shell substitutions, etc. 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
From: Robert Haas on 22 Jul 2010 09:09
On Wed, Jul 21, 2010 at 11:06 PM, David Christensen <david(a)endpoint.com> wrote: > > On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote: > >> Excerpts from Peter Eisentraut's message of mi� jul 21 10:24:26 -0400 2010: >>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote: >>>> 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. >>> >>> What is a use case for having .psqlrc be read in noninteractive use? >> >> Even if there weren't one, why does it get applied to -f but not -c? >> They're both noninteractive. > > > So not to let the thread drop, it appears that we're faced with the following situation: Hmm. I thought we almost had consensus on changing the historical behavior of -c. If we do that, this all gets much simpler. -- 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 |