On Tue, Aug 24, 2010 at 9:44 PM, Euler Taveira de Oliveira <eu...@timbira.com> wrote: > Robert Haas escreveu: >> On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira >> <eu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
