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
<craig@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".
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
