couple notes on readme about activerecord-pg_enum HOT 4 CLOSED

The primary reason why I wanted to use string enums in the first place was the opacity of having integers in the SQL output, so yes while you can avoid one particular footgun with the enum helper by being more explicit, it doesn't solve the core problem.

I was only noting the size of the enum bytes to illustrate that you're not paying a significant cost by using them, I doubt the difference between four or two bytes would really matter to most people. It's noteworthy that enums are not integers in PostgreSQL because they use a floating point to support adding a new value in between existing ones.

from activerecord-pg_enum.

The primary reason why I wanted to use string enums in the first place was the opacity of having integers in the SQL output

ahh, gotcha

It's noteworthy that enums are not integers in PostgreSQL because they use a floating point to support adding a new value in between existing ones.

I don't think that's true

https://www.postgresql.org/docs/13/datatype-enum.html#id-1.5.7.15.8

"Existing values cannot be removed from an enum type, nor can the sort ordering of such values be changed, short of dropping and re-creating the enum type. An enum value occupies four bytes on disk. "

from activerecord-pg_enum.

I said adding a new value, not changing an existing one.

https://www.postgresql.org/docs/13/catalog-pg-enum.html

When an enum type is created, its members are assigned sort-order positions 1..n. But members added later might be given negative or fractional values of enumsortorder. The only requirement on these values is that they be correctly ordered and unique within each enum type.

This is how they support adding new values before or after existing values

from activerecord-pg_enum.

Ah gotcha - I guess I need to grok this more. Thanks for the discussion!

from activerecord-pg_enum.