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:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Query optimization problem
Next
From: Robert Haas
Date:
Subject: Re: reducing NUMERIC size for 9.1