Re: Explicit psqlrc - Mailing list pgsql-hackers
From | David Christensen |
---|---|
Subject | Re: Explicit psqlrc |
Date | |
Msg-id | 8AD8B5A2-DD03-4564-94A9-98B1E5809108@endpoint.com Whole thread Raw |
In response to | Re: Explicit psqlrc (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Explicit psqlrc
|
List | pgsql-hackers |
On Jul 20, 2010, at 9:05 AM, Robert Haas wrote: > On Tue, Jul 20, 2010 at 10:00 AM, David Christensen <david@endpoint.com> wrote: >> Sorry for the delays in response. This is fine; I think there are some semantic questions that should still be resolvedat this point, particularly if we're moving toward supporting multiple -c and -f lines as expressed (an idea thatI 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/fileis 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 atthis 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 changeto a queue of structs; I think in that case, we'd want to modify the current .psqlrc handling to push a struct representingthe .psqlrc file at the front of the queue, depending on the code paths that currently set this up. Are thereany 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 script.sql`. 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 runningscripts 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 toexplicitly include .psqlrc (or the user could just specify -f path/to/psqlrc). Regards, David -- David Christensen End Point Corporation david@endpoint.com
pgsql-hackers by date: