On Wed, Dec 16, 2009 at 7:07 PM, Tom Lane wrote:
> Chris Travers writes:
>> It looks like this could be added without a disruption to programmer
>> interfaces, but it seems like any major change in this area would
>> create binary compatibility issues (i.e. require recompile of linked
>> software
Chris Travers writes:
> It looks like this could be added without a disruption to programmer
> interfaces, but it seems like any major change in this area would
> create binary compatibility issues (i.e. require recompile of linked
> software). Is this correct in what you mean by API incompatibi
Just to be clear (before I consider attempting a patch maybe I can
hand off to someone else to double-check)...
On Wed, Dec 16, 2009 at 5:31 PM, Tom Lane wrote:
> Yeah. The problem is that the only infrastructure libpq has for returning
> individual error message fields (like the SQLSTATE) is a
Chris Travers writes:
> 2) As of 8.1, tshark shows that the server does send the SQLSTATE to
> the client regarding why the login fails (for example 3D000 in the
> case of bad db name). Libpq as far as I can tell (from reading the
> code) doesn't do anything with this code. Certainly there seems
Hi Tom and everyone else;
After significant additional research this is what I have turned up:
1) The problem was a problem in DBD::Pg which didn't quite succeed in
setting the connection state to 08006. I have submitted a patch for
that to the DBD::Pg project.
2) As of 8.1, tshark shows that t
On Wed, Dec 16, 2009 at 1:39 PM, Tom Lane wrote:
> Chris Travers writes:
>> trying again. Sorry for the duplicate.
>> On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
>>> Exactly what "frontend" are you talking about here? Because what this
>>> sounds like to me is a client-side programming er
Chris Travers writes:
> trying again. Sorry for the duplicate.
> On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
>> Exactly what "frontend" are you talking about here? Because what this
>> sounds like to me is a client-side programming error. It's certainly
>> not the backend's fault, and I d
trying again. Sorry for the duplicate.
On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
> "Chris Travers" writes:
>> I am noticing that that a failed database connection results in an unusable
>> SQLSTATE in libpq, and a very different SQLSTATE than the backend
>> registers.
>
>> For example, i
"Chris Travers" writes:
> I am noticing that that a failed database connection results in an unusable
> SQLSTATE in libpq, and a very different SQLSTATE than the backend
> registers.
> For example, if a connection fails due to a database not found, the backend
> registers 3D000 as a SQL state, bu
On Wed, Dec 16, 2009 at 12:35 PM, Kevin Grittner
wrote:
> "Chris Travers" wrote:
>
>> I am noticing that that a failed database connection results in an
>> unusable SQLSTATE in libpq, and a very different SQLSTATE than the
>> backend registers.
>
> Well, if the client fails to connect to the serv
"Chris Travers" wrote:
> I am noticing that that a failed database connection results in an
> unusable SQLSTATE in libpq, and a very different SQLSTATE than the
> backend registers.
Well, if the client fails to connect to the server, I'm not sure how
the server could communicate its SQLSTATE t
The following bug has been logged online:
Bug reference: 5246
Logged by: Chris Travers
Email address: chris.trav...@gmail.com
PostgreSQL version: 8.1.18
Operating system: Fedora Linux 12
Description:Misleading/inconsistent SQLSTATE behavior
Details:
Hi all;
I am no
12 matches
Mail list logo
