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:
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
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
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?
> regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Vincent Pinto||Date: 2009-12-17 10:10:29|
|Subject: BUG #5248: Cannot find SSLEAY32.dll problem.|
|Previous:||From: Tom Lane||Date: 2009-12-17 03:07:06|
|Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior |