> But well, personally, I would ignore the feature and go without enum types (notice that it's a recent addition).

Postgres has had enums since 2008

I still don't totally understand that first point. Are you talking about using enums for controlling the connection itself? Can you give an example?

Just to clarify, sqlalchemy supports any arbitrary mapping you want — it's entirely flexible in every direction.

EDIT ah, do you mean something like this?

    CREATE FUNCTION do_thing(flags custom_enum)

Hiya Aidan! :D

> Is this behaviour new?

Don't think so. Even the docs for SQLA v1.3 ([0]) mention it:

> native_enum – Use the database’s native ENUM type when available. Defaults to True. When False, uses VARCHAR + check constraint for all backends. The VARCHAR length can be controlled with Enum.length

[0]: https://docs.sqlalchemy.org/en/13/core/type_basics.html#sqla...

--

> Or is it that alembic still doesn't pick up changes to the enum to recreate the constraint?

Off the top of my head, I believe Alembic doesn't pick it up automatically. We make a lot of manual tweaks to our auto-generated Alembic migrations and I believe adding / modifying the CHECK constrains is part of it.