On Jul 20, 2010, at 9:05 AM, Robert Haas wrote:

> On Tue, Jul 20, 2010 at 10:00 AM, David Christensen <da...@endpoint.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.  :-(

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 

psql -c "select 'starting'" -f file1.sql -c "select 'midway'" -f file2.sql -c 
"select 'done!'"

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).


David Christensen
End Point Corporation

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to