Question regarding enum backward compatibility

[Leulz]

First of all, thank you for the work done on this library, it has been very useful!

One thing that I would like to understand is the fact that rust-postgres apparently expects the Rust enums to have all possible variants of a Postgres enum, as seen in these tests. Is that correct?

If so, then does it mean that there is no backward compatibility? If I run a migration that adds an enum value, for example, I have to always ensure that a new deployment that has that new variant in the Rust enum will be deployed ASAP?

I wanted the behavior to be that as long as I am not trying to serialize/deserialize the value of a new enum value that does not exist on Rust's or Postgres's side, it would still work. Is it possible to have this behavior? Or is the implementation inherently not backward compatible?

[sfackler]

Yes, the generated implementations currently expect an exact match of both the type name and variant names.

The string representation of the enum variant is what's sent over the wire, so there is no hard requirement that the Rust type is an exact match of the Postgres type, but the check is potentially nice in surfacing mismatches immediately rather than deferring the problem to the first time the bad variant is sent or received.

We could add an option to the code generation to disable the variant comparisons potentially.

[viniciusth]

Hi, I work in the same company as @Leulz and it would be very nice if we could add an override to allow mismatching Rust and Postgres enum types, the expected behavior would be to return correctly if the Postgres return value is in the Rust Enum and error otherwise.

What do you think @sfackler? If it's okay I could implement this feature.

[sfackler]

Sure, I'd take a PR adding that.