Hey all,
Okay, as Robert points, 0 code in successful messages seems as waste
of bytes. But according to the documentation, All messages emitted by the
PostgreSQL server are assigned five-character error codes that follow the
SQL
standard's conventions for SQLSTATE codes. - the first sentence
On Wed, Sep 22, 2010 at 4:18 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
Okay, as Robert points, 0 code in successful messages seems as waste
of bytes. But according to the documentation, All messages emitted by the
PostgreSQL server are assigned five-character error codes that follow the
Robert Haas robertmh...@gmail.com wrote:
I'm not even sure that it would be correct to say All error
messages..., unless elog(ERROR, can't happen) throws something
into that field.
If it doesn't, it should. Probably 'XX000' (internal_error).
-Kevin
--
Sent via pgsql-hackers mailing
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 22, 2010 at 4:18 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
Okay, as Robert points, 0 code in successful messages seems as waste
of bytes. But according to the documentation, All messages emitted by the
PostgreSQL server are assigned
Tom Lane escreveu:
You didn't actually read what I said, did you? That patch will have
precisely zero effect on the OP's example.
Oh, I see your point. Didn't pay attention at the OP's example. I was only
worried about the successful queries that doesn't return SQLSTATE but as you
point out,
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 0 ? */
const char* sqlstate = Pg::PQresultErrorField(res, PG_DIAG_SQLSTATE);
That's because the protocol doesn't set error field when the
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 0 ? */
const char* sqlstate = Pg::PQresultErrorField(res, PG_DIAG_SQLSTATE);
That's because the protocol doesn't set
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 0 ? */
const char* sqlstate =
Robert Haas robertmh...@gmail.com writes:
I suppose we could change the function to return 0 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
Robert Haas escreveu:
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'm
Tom Lane escreveu:
The real issue
here is that there are no SQLSTATEs assigned for any error/warning
conditions generated internally in libpq.
Did you mean successful conditions? Only warning/error conditions produce a
SQLSTATE.
As far as this particular example goes, I think it's highly
Euler Taveira de Oliveira eu...@timbira.com writes:
What I'm thinking is something like
You didn't actually read what I said, did you? That patch will have
precisely zero effect on the OP's example.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Dmitriy Igrishin escreveu:
/* NOT presents - NULL. Why not 0 ? */
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
13 matches
Mail list logo
