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 03:44:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Wed, Dec 16, 2009 at 7:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Chris Travers <chris(at)metatrontech(dot)com> 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  incompatibility?
> No, I'm concerned about the programmer interface at the moment.  What
> have you got in mind?

My thinking (rather hackish) was to  do as follows:

(Rough version)
1)  Add an errFields member to pg_conn similar to what exists in pg_result
2) create a "dummy" pgResult instance inside the connection object to
track the messages (thus use internally any functions to store
errorfields there)
3)  Store error message fields using the errFields section of the
pgResult using whatever standard methods currently used for pgResult
4)  Copy over to connection struct
5)  Create a new function to expose this to the application. Maybe
named PQresultErrorField.

Then test this and make sure it works....

Then refine as follows:
1)  Refactor any errfields/Alloc-type functions as possible to get rid
of the necessity to go through a dummy result struct.  Remove the
dummy result struct and copy fields manually.  Maybe refactor the
field checking to centralize it between the result and connection

Then test this to make sure it works again.  Then see if I can get
someone else to further comment on/review/refine the patch.

>> ... The problem I was running into is that if the
>> user enters a non-existant database, the program would prompt for
>> username/password instead of letting them know the database was wrong.
>> My workaround at the moment is to check the error message against a
>> configurable value to see if it represents a missing database.  It
>> sucks because it means that foreign locale users must go through extra
>> configuration steps.  If I had the SQLSTATE data it would  be easy to
>> set up so that wouldn't be needed.
> We do have a workaround for distinguishing "password required" from
> other errors without any locale-specific tests.  It is surely a crock,
> but you'd want to use that in the near term anyway.  Any real fix here
> could not appear before 8.5 at the earliest.

What sort of current workarounds are there?

Best Wishes,
Chris Travers

>                        regards, tom lane

In response to

pgsql-bugs by date

Next:From: Vincent PintoDate: 2009-12-17 10:10:29
Subject: BUG #5248: Cannot find SSLEAY32.dll problem.
Previous:From: Tom LaneDate: 2009-12-17 03:07:06
Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior

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