Re: Select after insert to the unique column - Mailing list pgsql-general

From juleni@livetrade.cz
Subject Re: Select after insert to the unique column
Date
Msg-id 3223019531.20041213170417@livetrade.cz
Whole thread Raw
In response to Re: Select after insert to the unique column  ("Frank D. Engel, Jr." <fde101@fjrhome.net>)
Responses Re: Select after insert to the unique column  (Bruno Wolff III <bruno@wolff.to>)
List pgsql-general
Thank you for your answer. I think it's very interesting behaviour. Is
it a feature or bug ?

   I have try this my jUnit test for another DB systems (e.g. Oracle 9i,
MS SQL Server 2000, MySQL, DB2, Sybase, SAP DB) and it works for each of
these databases (it was possible tu run next command successfully after
an exception occured before).

  With baset regards,

  Julian Legeny


Monday, December 13, 2004, 4:26:24 PM, you wrote:

FDEJ> If you attempted the inserts within a single transaction and any of
FDEJ> them fail, they will all fail.  The server will automatically undo any
FDEJ> and all changes made by the transaction, and any further steps in the
FDEJ> transaction will simply result in the error message you are getting.
FDEJ> You will not be able to (successfully) issue any further database
FDEJ> commands until you end the transaction and start a new one.

FDEJ> On Dec 11, 2004, at 2:29 PM, Bruno Wolff III wrote:

>> On Wed, Dec 08, 2004 at 14:50:04 +0100,
>>   Julian Legeny <legeny@softhome.net> wrote:
>>> Hello,
>>>
>>>    Then I want to process command
>>>       select count(*) from UNIQUE_COLUMN_TEST
>>>    that I want to know how many records was already inserted before id
>>>    faied.
>>>
>>>    But when I try to process that SELECT COUNT(*), there is error
>>>    occured again:
>>>
>>>    org.postgresql.util.PSQLException:
>>>    ERROR: current transaction is aborted, commands ignored until end
>>> of transaction block
>>>
>>>    How can I solve this?
>>
>> Depending on what you really want to do, you could do each insert in
>> its
>> own transaction.
>>
>> If you don't want any of the inserts to succeed if there are problems,
>> then
>> you should do the counting in the application doing the inserts.
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>>
>>


pgsql-general by date:

Previous
From: "Frank D. Engel, Jr."
Date:
Subject: Re: relation "sql_features" does not exist
Next
From: Bruno Wolff III
Date:
Subject: Re: table with sort_key without gaps