I will show you fixed version patch later, please wait for a
> It's more important to not destabilize V3 code.
Ok, I withdraw that agreeing with that point. And I noticed that
the proposal before is totally a crap becuase I have mixed up
asyncStatus with resultStatus in it.
> And error from row processor is not something special from
> other errors. Why does it need special state?
I'm sorry to have upset the discussion. What I wanted there is a
means other than exceptions to exit out of PQexec() by row
processor trigger without discarding the result built halfway,
> I just asked you to replace ->rowProcessorErrMsg with ->errMsg
> to get rid of unnecessary field.
Ok, I will remove extra code.
> Also, with the PQgetRow() patch, the need for doing complex processing
> under callback has decreased and the need to set error outside callback
> has increased.
> As a bonus, such generic error-setting function would lose any extra
> special state introduced by row-processor patch.
That sounds nice. I will show you the patch without it for the
present, then try to include.
> Previously I mentioned that callback would need to have additional
> PGconn* argument to make connection available to callback to use such
> generic error setting function, but now I think it does not need it -
> simple callbacks don't need to set errors and complex callback can make
> the PGconn available via Param. Eg. the internal callback should set
> Param to PGconn, instead keeping NULL there.
I agree with it.
NTT Open Source Software Center
In response to
pgsql-hackers by date
|Next:||From: Lucky Haryadi||Date: 2012-02-28 03:05:52|
|Subject: Hot Standby Failover Scenario|
|Previous:||From: Alvaro Herrera||Date: 2012-02-28 02:18:22|
|Subject: Re: Trigger execution role (was: Triggers with DO functionality)|