Craig, I think that failure of a previous command is the most possible reason. It is an unexpected discovery since I keep track of statements that were already prepared on the connection (to avoid preparing a statement twice). However, the code might be flowed somehow. Anyway, I decided to use PQexec for the time being.
Cédric, I'm basically using a code similar to one in pgloader. I'm trying to find a way to efficiently handle an integrity violation error when inserting large amount of data. Graceful handling means that a transaction should not be aborted when the code tries to insert a duplicate row. Is using of a SAVEPOINT only solution? Thank you Konstantin On Tue, Oct 5, 2010 at 4:13 AM, Craig Ringer <cr...@postnewspapers.com.au>wrote: > On 10/05/2010 12:39 PM, Konstantin Izmailov wrote: > >> Howdy, >> I've noticed that there is a difference in result of execution of the >> following statement: >> INSERT INTO testtable(col1) VALUES(NULL); >> depending on whether the command is prepared or not. >> >> If I call PQprepare/PQexecPrepared for the statement, the error >> "transaction aborted" is returned with SQL State = "25P02". >> > > Specifically, I suspect the message should be: > > ERROR: current transaction is aborted, commands ignored until end of > transaction block > > If that's what you're getting, the problem was with an earlier command that > returned an error you didn't notice, not with the command you just ran. I'm > unsure if this could cause PQexecPrepared to return sqlstate 25P02 if > PQprepare fails, but would want to investigate the possibility. > > -- > Craig Ringer >
