Re: Interpreting PostgreSQL error messages
От | Tom Lane |
---|---|
Тема | Re: Interpreting PostgreSQL error messages |
Дата | |
Msg-id | 1287.1130297661@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Interpreting PostgreSQL error messages (Christoph Zwerschke <cito@online.de>) |
Ответы |
Re: Interpreting PostgreSQL error messages
|
Список | pgsql-interfaces |
Christoph Zwerschke <cito@online.de> writes: > I know there is a "SQLSTATE" code and the doco says: > "Applications that need to know which error condition has occurred > should usually test the error code, rather than looking at the textual > error message. The error codes are less likely to change across > PostgreSQL releases, and also are not subject to change due to > localization of error messages. " > But first, SQLSTATE is not accesible from many programming interfaces, So you need to use a less broken interface... > and second, anyway it would not help because it would not contain a hint > about for instance, which foreign key constraint has been violated. The SQL spec thinks that error reports should contain additional optional fields, such as "name of affected table" and "name of affected column" for a column constraint violation error. (I'm handwaving here but that's the general idea. The SQLSTATE code would tell you which additional fields are available.) Providing such fields would eliminate the need for client-side code to parse human-readable messages. We have not got round to implementing any of this yet, but the protocol and backend error-handling infrastructure are prepared to deal with extra fields of this ilk. Obviously, whenever that does happen, you'll need an even less broken client library to get at the extra fields. So if you open the bidding by saying "I won't use a tool that has heard of SQLSTATE", the answer is going to be "tough luck". regards, tom lane
В списке pgsql-interfaces по дате отправления: