Skip site navigation (1) Skip section navigation (2)

Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior

From: Chris Travers <chris(at)metatrontech(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chris Travers <chris(dot)travers(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior
Date: 2009-12-17 01:14:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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 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 to be
no exposure of the SQLSTATE to anything as it relates to a failed
connection attempt.  I could be missing something because I am not
extremely familiar with the libpq codebase, but it seems that the
value is just discarded.

Are there any plans to expose the SQLSTATE from a failed connection
attempt upwards through the library?  (I would be happy to try to
write a patch but you probably don't want my C code in your library.)

Best Wishes,
Chris Travers

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2009-12-17 01:31:27
Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior
Previous:From: Mark KirkwoodDate: 2009-12-16 22:59:23
Subject: Re: BUG #5244: Attempting to rollback to a savepoint after receiving an error with state 55000 the process hangs

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group