From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Assignment scheme for implementation-defined error codes? |
Date: | 2003-07-28 09:26:55 |
Message-ID: | Pine.LNX.4.56.0307281112390.2256@krusty.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm currently fixing up ecpg for the new error codes. (ecpg was doing
string comparisons to detect certain failure conditions, which no longer
works, so this is a must-fix.) Many of the failure conditions that ecpg
detects explicitly can be mapped to SQLSTATE codes that are defined in the
standard or have been assigned for use by the backend. Some codes,
however, will end up being specific to ecpg. I'm wondering what kind of
scheme we should use to allow clients to reserve some SQLSTATE codes for
their own use.
The errors I'm currently looking at can be thought of as "internal
errors", so should I be using the class XX, or maybe XY as internal error
on the client side, or maybe YE as internal error on the client side in
ecpg (so YL could be libpq, YO the ODBC driver, etc.)?
What about creating client-specific subclasses of existing classes?
Is the DB2 SQLSTATE reference, where some codes were apparently taken
from, available somewhere? (A web search doesn't show anything useful.)
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2003-07-28 12:39:45 | Re: developer.postgresql.org is broken |
Previous Message | Peter Eisentraut | 2003-07-28 09:10:39 | Warning for undefined cursor |