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
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 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).
Regards,
David
--
David Christensen
End Point Corporation
da...@endpoint.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
