Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior

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
structs.
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
functions?

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
>