Re: SQLSTATE of notice PGresult

From: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQLSTATE of notice PGresult
Date: 2010-08-25 02:50:31
Message-ID: 4C7484F7.1030000@timbira.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 referring to [1].

> 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.
>
It seems we can't infer the success message from libpq; it is necessary to
build the sql state message field. As I said both behaviors have the same goal
(in this case, NULL means success, i.e. sqlstate is not assigned) but it
doesn't match the spec.

[1] http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html

--
Euler Taveira de Oliveira
http://www.timbira.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2010-08-25 03:04:38 Re: SQLSTATE of notice PGresult
Previous Message Tom Lane 2010-08-25 02:36:01 Re: SQLSTATE of notice PGresult