Explicit psqlrc
in [PgSql]
|
Prev: [PATCH] elimination of code duplication in DefineOpFamily()
Next: [HACKERS] trace_recovery_messages
From: Robert Haas on 21 Jun 2010 21:16 On Mon, Jun 21, 2010 at 9:13 PM, Stephen Frost <sfrost(a)snowman.net> wrote: > * Robert Haas (robertmhaas(a)gmail.com) wrote: >> So none of the above sounds like desired behavior to me... �is that just me? > > Yeah, I'm not really thrilled with this.. �I mentioned earlier what I > thought would be a useful feature (basically, a switch which would > ignore the main psqlrc and turn on the various options that make sense > for a script), but that seems to have fallen to the wayside.. Well, that might be a good idea, too, but my expectation is that: psql -f one -f two -f three ought to behave in a manner fairly similar to: cat one two three > all psql -f all and it sounds like with this patch that's far from being the case. -- 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: Stephen Frost on 21 Jun 2010 21:13 * Robert Haas (robertmhaas(a)gmail.com) wrote: > So none of the above sounds like desired behavior to me... is that just me? Yeah, I'm not really thrilled with this.. I mentioned earlier what I thought would be a useful feature (basically, a switch which would ignore the main psqlrc and turn on the various options that make sense for a script), but that seems to have fallen to the wayside.. Thanks, Stephen
From: Simon Riggs on 22 Jun 2010 04:34 On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote: > On Mon, Jun 21, 2010 at 7:51 PM, gabrielle <gorthx(a)gmail.com> wrote: > > On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked: > >> How does it play with ON_ERROR_STOP/ROLLBACK? > > > > With ON_ERROR_STOP=ON, psql issues an error when it encounters one, > > stops processing the file that contains the error, and then continues > > to process any remaining files. That would be undesirable. > > I'm still investigating ON_ERROR_ROLLBACK. I need to tinker with it > > some more before I say anything concrete. > > > > On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > >> Also, how does it play with --single-transaction. > > That was buried in our original report :) "BEGIN-COMMIT statements > > within the files cause warnings when the command is wrapped in a > > transaction with the -1 switch (as specified in the patch submission)" > > > > To expand upon that a bit: when psql encounters a file that contains > > a BEGIN statement, you get the expected "WARNING: there is already a > > transaction in progress" message. The COMMIT at the end of that file > > (assuming the user doesn't forget it) generates a COMMIT. Commands > > after that commit, or in any remaining files to be processed, are > > dealt with according to the user's autocommit settings: > > - if autocommit is ON, statements in the remaining files are processed > > & committed; the implicit COMMIT at the end of the whole thing then > > generates a "WARNING: there is no transaction in progress" message > > - if autocommit is OFF, statements in the remaining files generate > > "ERROR: current transaction is aborted, commands ignored until end of > > transaction block" messages. This is the existing behaviour. > So none of the above sounds like desired behavior to me... is that just me? Single transaction needs some help, but that's not the fault of this patch. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- 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: gabrielle on 23 Jun 2010 09:17 On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > Well, that might be a good idea, too, but my expectation is that: > > psql -f one -f two -f three > > ought to behave in a manner fairly similar to: > > cat one two three > all > psql -f all > > and it sounds like with this patch that's far from being the case. Correct. Each is handled individually. Should I continue to check on ON_ERROR_ROLLBACK results, or bounce this back to the author? gabrielle -- 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 23 Jun 2010 09:22
On Wed, Jun 23, 2010 at 9:17 AM, gabrielle <gorthx(a)gmail.com> wrote: > On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> Well, that might be a good idea, too, but my expectation is that: >> >> psql -f one -f two -f three >> >> ought to behave in a manner fairly similar to: >> >> cat one two three > all >> psql -f all >> >> and it sounds like with this patch that's far from being the case. > > Correct. �Each is handled individually. > > Should I continue to check on ON_ERROR_ROLLBACK results, or bounce > this back to the author? It doesn't hurt to continue to review and find other problems so that the author can try to fix them all at once, but it certainly seems clear that it's not ready to commit at this point, so it definitely needs to go back to the author for a rework. -- 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 |