On Tue, Aug 24, 2010 at 9:44 PM, Euler Taveira de Oliveira
<euler@timbira.com> wrote:
> Robert Haas escreveu:
>> On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira
>> <euler@timbira.com> wrote:
>>> Dmitriy Igrishin escreveu:
>>>> /* NOT presents - NULL. Why not "00000" ? */
>>>> const char* sqlstate = Pg::PQresultErrorField(res, PG_DIAG_SQLSTATE);
>>>>
>>> That's because the protocol doesn't set error field when the command
>>> succeeded. IMHO it's an oversight (the documentation is correct but the code
>>> is not) and should be correct because the spec enforces it.
>>
>> Seems like a waste of bytes.
>>
> Ugh? It is a matter of correctness. I'm not arguing in favor of it but if we
> don't implement it, it is better document it.
<does a little more looking>
It appears to me that it already is documented. The very first
sentence of the documentation reads:
Returns an individual field of an error report.
And a few sentences later it says:
NULL is returned if the PGresult is not an error or warning result
> I don't actually rely on sql
> state to check errors but can have applications out there that expect the spec
> behavior but we don't provide it and, also fail to document it. Talking about
> the patch, it is just pqSaveMessageField() calls in *Complete messages. I can
> provide a patch for it.
I suppose we could change the function to return 00000 always when the
operation is not an error or warning report, rather than NULL, but
certainly we wouldn't want to include those bytes in *every* success
message, so they'd have to be something that the libpq inferred. And
I'm not clear why that behavior would be any more useful than what we
have now; indeed, it seems like it would needlessly break backward
compatibility. If you're arguing that this behavior is required by
the spec, let's have a cite. I find it a bit surprising that the spec
would cover the behavior of individual libpq functions in this level
of detail.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
