Re: Explicit psqlrc

On Jun 23, 2010, at 5:36 PM, Mark Wong wrote:

> On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote:
>
>> On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
>>> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle <gorthx@gmail.com> wrote:
>>>> On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
>>>>> How does it play with ON_ERROR_STOP/ROLLBACK?
>>>>
>>>> With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
>>>> stops processing the file that contains the error, and then continues
>>>> to process any remaining files.
>>
>> That would be undesirable.
>>
>>>> I'm still investigating ON_ERROR_ROLLBACK.  I need to tinker with it
>>>> some more before I say anything concrete.
>>>>
>>>> On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>>> Also, how does it play with --single-transaction.
>>>> That was buried in our original report :) "BEGIN-COMMIT statements
>>>> within the files cause warnings when the command is wrapped in a
>>>> transaction with the -1 switch (as specified in the patch submission)"
>>>>
>>>> To expand upon that a bit:  when psql encounters a file that contains
>>>> a BEGIN statement, you get the expected "WARNING: there is already a
>>>> transaction in progress" message.  The COMMIT at the end of that file
>>>> (assuming the user doesn't forget it) generates a COMMIT.  Commands
>>>> after that commit, or in any remaining files to be processed, are
>>>> dealt with according to the user's autocommit settings:
>>>> - if autocommit is ON, statements in the remaining files are processed
>>>> & committed;  the implicit COMMIT at the end of the whole thing then
>>>> generates a "WARNING: there is no transaction in progress" message
>>>> - if autocommit is OFF, statements in the remaining files generate
>>>> "ERROR:  current transaction is aborted, commands ignored until end of
>>>> transaction block" messages.
>>
>> This is the existing behaviour.
>>
>>> So none of the above sounds like desired behavior to me...  is that just me?
>>
>> Single transaction needs some help, but that's not the fault of this
>> patch.
>
> I took a closer look at what was going on and what it would take to meet some of these expectations.  In main() the
patchadds BEGIN and COMMIT statements outside the call to process_file() in src/bin/psql/command.c.  Here lies the
previouslogic for handling single transaction.  Since it remains, it appears that BEGIN can be issued twice before any
statementsare executed if the single transaction switch is used.  Plus there are other a couple of places that call
thisparticular process_file() function, but I think those are straightforward cases to deal with. 

Heh, not close enough.  I was wrong about that scenario.  I can see now that the single transaction flag is always set
tofalse in process_file().  I think that turns the single transaction handling in process_file() into dead code with
thepatch like this. 

Regards,
Mark