support adding PG enums as GraphQL enum types

[maxpain]

Why Hasura doesn't utilize Postgres ENUM types and doesn't translate them to GraphQL Enums?

[shahidhk]

We do not support Postgres ENUM types as of now. Will mark this as a feature request, give a 👍 if you'd like the feature added. 😄

Till then, you can use single-column tables.

[maxpain]

Any updates? It is a very important feature for us.

[0x777]

We had a discussion about this couple of days. We can go ahead with the implementation with some feedback from the community.

We understand that it is incredibly useful to propagate enums in your database to the GraphQL layer. There are couple of ways in which you typically model enums in the database.

1. Using Postgres enums: There are certain limitations with Postgres's enums, the most important one is that you can't delete a value from an enum.
2. The other option is to to use single-column tables for enums as documented here. This some consider is a better practice over using Postgres enum types.

We would like to know which pattern is commonly used so that we can do the appropriate propagation to the graphql layer.

[chunsli]

Is there a way to implement a text array, where each value is one of the enumerations. is there a way of doing this without a normalized table?

[trekze]

+1 for the second pattern @0x777

[lordofthelake]

I think it depends on the use case. For values that are likely to change over time, a separate table is better.

But for values that are "set in stone" (the examples that come to mind are static data like country codes, currencies, language codes, measurement units and the likes) a native Postgres enum would be very valuable (and I would argue, also a better practice – more efficient, less error prone).

[frankdugan3]

In my opinion, there is a lot of value in equating Postgres enums with GraphQL enums. Neither should change often, and the benefit is great documentation for the API. Using the single-column table pattern in this case would move the error for selecting an invalid value from something that could be checked statically at compile time (with tooling) to something only detected at runtime.

If the value is more flexible or even user defined, I think the single-column table pattern makes sense.