PgHasArrayType for transparent types fix. #2086
Conversation
Problem: PgHasArrayType was checking the application's postgres feature Solution: only check the library's postgres feature
| @@ -88,15 +88,21 @@ fn expand_derive_has_sql_type_transparent( | |||
| <#ty as ::sqlx::Type<DB>>::compatible(ty) | |||
| } | |||
| } | |||
| #[automatically_derived] | |||
| #[cfg(feature = "postgres")] | |||
There was a problem hiding this comment.
This line was making it so my application had to have a postgres feature which was enabled. 💢
|
Ah, wait. This is a breaking change, isn't it? Anyone who manually added a |
|
I didn't think about that, but you are probably correct. Still, the behavior of asking the application to create its own |
|
That was certainly a mistake in the implementation, the intended effect was to emit the block only when the Would you say that this is an acceptable breakage (derived types gaining the |
|
That's a pretty philosophical question, is the promise the code, or the documentation? I want this in a release so I'm pretty biased in my answer. 😛 FWIW, I just have a random |
|
Yeah, I suppose I'll just move this to another branch for now and release it with 0.7.0. |
|
Moved commit from |
Problem: PgHasArrayType was checking the application's postgres feature Solution: only check the library's postgres feature Co-authored-by: Daniel Tashjian <daniel@ecomedes.com>
Problem: PgHasArrayType was checking the application's postgres feature Solution: only check the library's postgres feature Co-authored-by: Daniel Tashjian <daniel@ecomedes.com>
Problem: PgHasArrayType was checking the application's postgres feature Solution: only check the library's postgres feature Co-authored-by: Daniel Tashjian <daniel@ecomedes.com>
Problem: PgHasArrayType was checking the application's postgres feature Solution: only check the library's postgres feature Co-authored-by: Daniel Tashjian <daniel@ecomedes.com>
caused by launchbadge#2086 closes launchbadge#2611 seems like launchbadge#2086 fixed issue described by @Wopple by making that block of code unreachable. Not as it was stated in > Problem: PgHasArrayType was checking the application's postgres feature > Solution: only check the library's postgres feature after checking https://doc.rust-lang.org/std/macro.cfg.html > `cfg!`, unlike `#[cfg]`, does not remove any code and only evaluates > to true or false. For example, all blocks in an if/else expression > need to be valid when `cfg!` is used for the condition, regardless of > what `cfg!` is evaluating. so to my understanding it would be `true` anyway in @woople scenario
Problem:
PgHasArrayTypewas checking the application'spostgresfeatureSolution: only check the library's
postgresfeatureThis wasn't fun to debug. 😅