Opened 6 years ago

Last modified 20 months ago

#219 new enhancement

Access to the sqlstate in pqxx::sql_error

Reported by: Andres Freund <andres@…> Owned by: jtv
Priority: highest Component: other
Severity: Incomplete Keywords:
Cc: andres@…, seltenreich@…

Description

Currently for most of the possible errors an sql_error is thrown with the errors message but not the sqlstate.

Given that there are loads of probable error codes that one can sensibly handle I think it would be sensible to put it in sql_error.

Is there any argument against doing so?

Change History (10)

comment:1 Changed 6 years ago by Andres Freund <andres@…>

  • Cc andres@… added

comment:2 Changed 6 years ago by jtv

I'd like to model as much of the knowledge about errors as possible in the exception hierarchy itself, rather than in error codes. But in principle there's nothing against including the error code.

If we want to do that, we may have to look into synthesis in cases where error codes are missing: if the front-end detects an error that would otherwise have lead to an error from the back-end, can and should it provide the corresponding error code? If so, to what extent can we allow that code to diverge from what the application may expect from the given backend version?

comment:3 Changed 6 years ago by Andres Freund <andres@…>

I'd like to model as much of the knowledge about errors as possible in the exception hierarchy itself, rather than in error codes. But in principle there's nothing against including the error code.

Totally for it. But given the vast amount of error codes I don't think its realistic to model and completely. Also the growth is rather fast (205 from 9.0 to 238 in 9.1 according to a quick grep).

If we want to do that, we may have to look into synthesis in cases where error codes are missing: if the front-end detects an error that would otherwise have lead to an error from the back-end, can and should it provide the corresponding error code? If so, to what extent can we allow that code to diverge from what the application may expect from the given backend version?

Are real sql_error's thrown for those cases? I couldn't quickly find any cases where that is happening. I would expect that nearly all those errors are thrown outside of the sql_error hierarchy. If there are such cases do you really see a problem throwing the same error code? I.e. something like invalid_cursor_name would be recognizable at the client - but the sqlstate for that is fixed for a long time. While I prefer synthesized error codes I can live without sqlstate for the most specific errors as those should be caught by using the more specific exception classes in most of the cases.

While at it I would suggest adding some of the other error fields. E.g. in a report writing environment its very useful to see the position of the error in an user generated query. Its not uncommon that they don't have direct access to the database or the error log.

comment:4 Changed 6 years ago by jtv

Yes, I'd love to add this information and mostly just haven't gotten around to it. On general principle I want to minimize complexity in exception classes (because error paths are usually less well-tested, and also because once things start breaking you want to stay away from machinery that might break further). But as long as we're talking about errors that are strictly on the server side, that's much less of a worry.

Any chance of a patch? :)

comment:5 Changed 6 years ago by Andres Freund <andres@…>

Any chance of a patch? :)

I already planned to write one ;). Just havent gotten around to do so.

comment:6 Changed 6 years ago by jtv

Still interested in a patch. Hoping to get 4.0 released soon, and it would be nice to have this in there!

comment:7 Changed 3 years ago by anonymous

  • Priority changed from normal to highest

Is there any chance to get a fix of this issue?

comment:8 Changed 2 years ago by Andreas Seltenreich <seltenreich@…>

  • Cc seltenreich@… added

comment:9 Changed 20 months ago by seltenreich@…

Is anyone working on this?

I'm in need too, but I don't known which classes are the proper place to modify. For example, the Standard has codes for errors that happen on the libpqxx side, and we could assign the proper codes for internal errors as well.

comment:10 Changed 20 months ago by anonymous

  • Severity changed from Other to Incomplete
Note: See TracTickets for help on using tickets.