From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Christensen <david(at)endpoint(dot)com> |
Cc: | gabrielle <gorthx(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Mark Wong <markwkm(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Explicit psqlrc |
Date: | 2010-07-20 14:05:04 |
Message-ID: | AANLkTimKua-M3Mo4XviQCA8SFf6_J0_9pGYGuR9DoPWZ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 20, 2010 at 10:00 AM, David Christensen <david(at)endpoint(dot)com> wrote:
> Sorry for the delays in response. This is fine; I think there are some semantic questions that should still be resolved at this point, particularly if we're moving toward supporting multiple -c and -f lines as expressed (an idea that I agree would be useful). Specifically:
>
> 1) Does the -1 flag with multiple files indicate a single transaction for all commands/files or that each command/file is run in its own transaction? I'd implemented this with the intent that all files were run in a single transaction, but it's at least a bit ambiguous, and should probably be documented at the very least.
I think your implementation is right. Documentation is always good.
> 2) I had a question (expressed in the comments) about how the final error handling status should be reported/handled. I can see this affecting a number of things, particularly ON_ERROR_{STOP,ROLLBACK} behavior; specifically, if there was an error, it sounds like it should just abort processing of any other queued files/commands at this point (in the case of ON_ERROR_STOP, at least).
Right. I think it should behave much as if you concatenated the files
and then ran psql on the result. Except with better reporting of
error locations, etc.
> 3) With the switch to multiple intermixed -c and -f flags, the internal representation will essentially have to change to a queue of structs; I think in that case, we'd want to modify the current .psqlrc handling to push a struct representing the .psqlrc file at the front of the queue, depending on the code paths that currently set this up. Are there any gotchas to this approach? (I'm looking essentially for odd code paths where say .psqlrc was not loaded before, but now would be given the proper input of -c, -f file, -f -.)
>
> I'll look more in-depth at the posted feedback and Mark's proposed patch.
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. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Wakeling | 2010-07-20 14:12:25 | Re: Trouble with COPY IN |
Previous Message | Kevin Grittner | 2010-07-20 14:04:26 | Re: Some git conversion issues |