Postgres enum types with an empty string as a valid value will break all parsing

[LouisGariepy]

Migrated from halcyonnouveau/clorinde#92, originally reported by @KenAKAFrosty on 2025-04-16.

Not sure if this should even be considered a bug.

Possibly something to just mention in the docs or a FAQ.

If you have an enum type like CREATE TYPE badge AS ENUM ('staff', 'maintenance', 'guest', '') , where you have an empty string value as a valid part of the enum, expect to see this error when running the CLI if your queries return that column:

thread 'main' panicked at ...
Ident is not allowed to be empty; use Option<Ident>
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Makes sense when you consider that the created Rust enum can't (and shouldn't) support an empty value inherently

One could argue that the type shouldn't contain the empty value, but instead allow for nullable columns where that type is used. I'm inclined to agree, but I'm short on a time machine to convince my old self of that 😅

Not a huge deal as I can work around this now that I know the issue. But if someone was dipping their toes into clorinde, and hit this kind of error, it may put them off. Would be a shame since they wouldn't get to see how awesome clorinde is!

Happy to hear thoughts on this. And I'm open to help with getting it somewhere in the docs if that's something we want!

---

Original discussion

@beanpuppy (2025-04-17):

Thanks for bringing this up. Having an empty string value in an enum doesn't seem like a very good idea, so I wouldn't really want to add support for this even if we could.

I'm not sure if we need to document it anywhere as I doubt many people would do something like this. But since it is technically valid postgres to do this, and we aim to have complete postgres support for every possible thing it could do, I can see how we might want it documented somewhere just for completeness and posterity.

We don't have a FAQ, but I'm not opposed to the idea of it, I don't know what else could be added to it though.

We could also have a "known limitations" document for things like this. Although the only other thing I can think of right now to add to it is halcyonnouveau#86, but there's probably more if I dug deeper and loosened my criteria for "limitation".

If it were just left to me, I'd probably leave it here and refer to this issue if anyone else comes and asks for it. But if you're really wanting to write some docs, you're free to open a PR with whatever you think is best.

[LouisGariepy]

I'm somewhat torn on this because on one hand an empty string enum value is clearly a niche anti-pattern which Cornucopia would be well within it's right to reject with an error message (instead of panicking, to be fair). On the other hand, Cornucopia is PostgreSQL-first and should not require the user to modify their database to accommodate it.

The PR fix suggested by @leno23 (linked in the thread) is sensible, but it introduces a collision risk when the enum has both '' and 'empty' variants. This is a niche case of an already niche case, but it kind of brings us back to square one in the sense that we'll still reject valid PostgreSQL.

So, I could be convinced one way or another (either to just emit an error, or to actually support this), but if we do chose to support this, I'd like to see an implementation that is guaranteed collision-less and that minimizes footguns.

[KenAKAFrosty]

Very thoughtful review! To add context that had slipped my mind on the original post made: this was actually borne out of honoring a third-party's API and keeping the types as direct to their data structure as possible. Those cases are where their guidance explicitly and specifically used empty string values as the psueudo-None variant, in what was otherwise string literal style enums. Still niche for sure, and one could choose to convert to null instead for a case like that, but there's at least a bit of method to that madness