Robert Haas writes:
> On Wed, Sep 22, 2010 at 4:18 AM, Dmitriy Igrishin 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 t
Robert Haas 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 list (pgsql-hacker
On Wed, Sep 22, 2010 at 4:18 AM, Dmitriy Igrishin 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
> SQL
> sta
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 sen
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
Euler Taveira de Oliveira 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 (pgsql-hackers@postgresql.org
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 highl
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
Robert Haas 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 the libpq inferred
On Tue, Aug 24, 2010 at 9:44 PM, Euler Taveira de Oliveira
wrote:
> Robert Haas escreveu:
>> On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira
>> wrote:
>>> Dmitriy Igrishin escreveu:
/* NOT presents - NULL. Why not "0" ? */
const char* sqlstate = Pg::PQresultErrorFiel
Robert Haas escreveu:
> On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira
> 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 e
On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira
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 command
> s
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
13 matches
Mail list logo
