launchbadge
Regression in v0.6 when decoding an PostgreSQL enum in a PgRecordDecoder
I don't have a complete reproduction at the moment although I could work on it.
The basic issue is that we're using a custom PostgreSQL enum, i.e. CREATE TYPE MyEnum AS ENUM ( ... ), and try to decode that from a PgRecordDecoder using try_decode. On the rust side the enum derives sqlx::Type nothing else special. In v0.5 this works fine, but in v0.6 it hits the following error:
error occurred while decoding column variables: custom types in records are not fully supported yet: failed to retrieve type info for field 4 with type oid 25101253
Where oid 25101253 is our enum. The error comes from: https://github.com/launchbadge/sqlx/blob/8fd7ee72a62449af592bf3c43d360a3d64f6195c/sqlx-core/src/postgres/types/record.rs#L136
Which was added in https://github.com/launchbadge/sqlx/pull/1855 (hence my comment there).
I just tried partially reverting #1855 with the following patch and that fixes the issue. Would that be an acceptable change?
diff --git a/sqlx-core/src/postgres/types/record.rs b/sqlx-core/src/postgres/types/record.rs
index 352bdb72..c2b1bcce 100644
--- a/sqlx-core/src/postgres/types/record.rs
+++ b/sqlx-core/src/postgres/types/record.rs
@@ -132,8 +132,7 @@ impl<'r> PgRecordDecoder<'r> {
}
let element_type =
- element_type_opt
- .ok_or_else(|| BoxDynError::from(format!("custom types in records are not fully supported yet: failed to retrieve type info for field {} with type oid {}", self.ind, element_type_oid.0)))?;
+ element_type_opt.unwrap_or_else(|| PgTypeInfo::with_oid(element_type_oid));
self.ind += 1;
Unfortunately, I think that's just going to bring back the panic in the array decode case, which you yourself reported in #1672.
@abonander that's unfortunate, but it's still a clear regression. Is there a middle road we can take? Maybe delay the creation of the error to the point where it previously panicked? This way at least the custom enum within a record will keep working.
Thank you for reporting this error. I was busy for a few weeks but still intend to refactor SQLx to fully support custom types. I am sorry for the regression.
I'll try to look into this in the next days.
@demurgos any update on this? I could look into this myself if you don't have the time.
This is still preventing us from updating, any news?
Me too— is this issue planned for 0.7?
