Problem parsing error severity for localized postgres instances #734
Comments
|
@dstoeckel that sounds like a good plan, please go ahead an open a PR. |
dstoeckel
added a commit
to dstoeckel/sqlx
that referenced
this issue
Oct 18, 2020
In order to support PostgreSQL <= 9.5, the b'S' field of an error/notice message was parsed. However, this field can be localized and thus parsing can fail for instances that use a non-english locale. In version > 9.5, the b'V' field, that is guaranteed to be in english, was added. However, even for these versions parsing would fail as the b'S' field was also parsed. This patch prefers b'V' over b'S' if it exists and uses a default severity in case b'V' is not present and b'S' could not be parsed. Fixes launchbadge#734
dstoeckel
added a commit
to dstoeckel/sqlx
that referenced
this issue
Oct 18, 2020
In order to support PostgreSQL <= 9.5, the b'S' field of an error/notice message was parsed. However, this field can be localized and thus parsing can fail for instances that use a non-english locale. In version > 9.5, the b'V' field, that is guaranteed to be in english, was added. However, even for these versions parsing would fail as the b'S' field was also parsed. This patch prefers b'V' over b'S' if it exists and uses a default severity in case b'V' is not present and b'S' could not be parsed. Fixes launchbadge#734
dstoeckel
added a commit
to dstoeckel/sqlx
that referenced
this issue
Oct 18, 2020
In order to support PostgreSQL <= 9.5, the b'S' field of an error/notice message was parsed. However, this field can be localized and thus parsing can fail for instances that use a non-english locale. In version > 9.5, the b'V' field, that is guaranteed to be in english, was added. However, even for these versions parsing would fail as the b'S' field was also parsed. This patch prefers b'V' over b'S' if it exists and uses a default severity in case b'V' is not present and b'S' could not be parsed. Fixes launchbadge#734
abonander
pushed a commit
that referenced
this issue
Oct 19, 2020
In order to support PostgreSQL <= 9.5, the b'S' field of an error/notice message was parsed. However, this field can be localized and thus parsing can fail for instances that use a non-english locale. In version > 9.5, the b'V' field, that is guaranteed to be in english, was added. However, even for these versions parsing would fail as the b'S' field was also parsed. This patch prefers b'V' over b'S' if it exists and uses a default severity in case b'V' is not present and b'S' could not be parsed. Fixes #734
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Commit c9eef8b introduces parsing the the
Sfield of an error / notice message in order to fix severity recognition for versions <= 9.5. Unfortunately this regresses localized databases (e.g. lc_messages = fr_FR.UTF8) for versions >= 9.6, because theSfield is also localized and thus an "unknown severity" error is generated.A potential fix could be to parse the two fields separately (say
severity_v: Option<PgSeverity>andseverity_s: Option<PgSeverity>) and then doing aseverity_v.or(severity_s).unwrap_or(PgSeverity::Log). If this sounds like the right approach I can come up with a patch.The text was updated successfully, but these errors were encountered: