Re: Is there a logical reason for 25P02?

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(at)postnewspapers(dot)com(dot)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
>