New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Constants for PostgresException.SqlState #1300
Comments
I'm not sure I see great value coming from this, but it could make sense to include it in Npgsql. The list would have to be kept up to date (although I'm not sure how frequently error codes are added). Regarding the duplicate error names, rather than putting all error codes under a "namespace', I'd simply prefix the problematic values (e.g. If you submit a PR on this I'll merge it. |
Prefixing sounds fine, I had intentionally left it out because I'm usually against introducing "exceptions" in favor of uniformity, but I would have no objections to renaming those few offending identifiers. If however you think this class would impose maintenance burden, I'm perfectly ok with you deciding not to include it. I'm not sure either how frequently error codes are added, and one could also think of adding them "on demand" if a user opens an issue pointing out a certain error code is missing. I can make a PR in the coming days, no problem, but if you feel it brings too little to the table I have, like I said, no objections at all. It is just something I did for me, so if it doesn't suit anybody else it's not a big deal. |
I don't think there's lots of movement in the error code space, and as you say we can always add more. Feel free to submit a PR (it may take a bit of time for me to look at it though, am about to go on vacation). |
No problems at all, enjoy your vacation then! |
Am going to close this issue, a PR on this would be accepted though. |
How is it going? |
@roji has this been added in some fashion, i'd be happy to help with a PR to add something like this |
@daniel-white this hasn't been added. I think we'd accept a PR doing this, although let's see what @YohDeadfall and @austindrenski think. |
@roji cool. i would not make these as |
@daniel-white do you mean in case of code changes on the PostgreSQL side? |
@roji no in this library, if theres another error message added |
I may be misunderstanding, but why would adding a new |
well i guess i'm wrong but its your call. |
I don't have very strong feelings either way: I think PostgreSQL error codes are a rare case where public |
I'm voting for |
Hello, I was wondering if a static class that grouped all the possible error codes as documented here would be a worthwhile addition to
Npgsql
.I recently needed to inspect the
SqlState
property to figure out what went wrong and act accordingly and, from what I could see, there is no such class that would hide the 5-characters error code behind a more friendly name.One catch is that a few of the error codes in the linked page have different codes but the same condition identifier, so just transforming them from
snake_case
toPascalCase
to name the constants properly is going to cause a compilation error (see for instancenull_value_not_allowed
, which is both aData Exception
with code22004
and anExternal Routine Invocation Exception
with code39004
).Assuming such a
SqlStates
class has any value, the obvious workaround would be to nest static classes to group constants into poor man's namespaces. Nested classes would have names that identify the error class, but this might lead to overly long names (especially for classes likeSyntax Error or Access Rule Violation
).Client code would look like:
All of this might have already been considered and discussed before, and a
SqlStates
class is just not there exactly because there is no elegant and concise way to solve duplicated error identifiers. If so I apologize.I'm attaching the class with all the error condition identifiers already converted to PascalCase should it ever come in handy. It's based on the current documentation. As I said it doesn't currently compile.
The text was updated successfully, but these errors were encountered: