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.

[drewwestphal]

Another issue to consider in supporting this feature is the migration side. As you can see from the below, adding values to an enum type is not possible within "transactional migrations" (or transactions generally)

https://stackoverflow.com/questions/1771543/adding-a-new-value-to-an-existing-enum-type/10404041#10404041

[respectTheCode]

Looks like this might be a blocker for us. We use ENUMs in our existing database and I am getting an error stating that my schema is invalid from the GraphQL CLI.

[respectTheCode]

false alarm. my problem was related to having a row permission with no columns selected. once I fixed that the schema worked.

[Krever]

Hey, this is also a problem with codegen tools, that relies on schema to generate proper enums. Right now possible enum values cannot be detected by such tools as postgres enums are translated to grpahql scalar types.

[mnlbox]

@Krever why you use third party schema generator when we have console app for Hasura 🤔
Any use-case?

[Krever]

@mnlbox I may not have phrased myself clearly enough. Im using codegen tool to generate scala code which will be used as a hasura client. The codegen relies on schema returned by hasura via introspection.

Let me know if you need any more details.

[Fxlr8]

any updates on this one?

[respectTheCode]

any updates?

[respectTheCode]

Does that PR add support for Postgres ENUMs? The description seems to describe a different feature.

[kylerjensen]

Does that PR add support for Postgres ENUMs? The description seems to describe a different feature.

@respectTheCode: From the looks of it, it appears that #2672 does not add support for exposing Postgres enums as Graphql enums. The maintainers may want to consider reopening this issue since the "fix" does not actually accomplish what was requested.

I would love to see another PR that adds support for exposing Postgres enums as GraphQL enums, and leaves the current functionality intact. It would be nice to have the option to use either mechanism. There seem to be some good arguments for both approaches.

[kylerjensen]

Note: It looks like Postgres 12 will include support for adding enum values within a transaction. https://www.postgresql.org/docs/12/sql-altertype.html

[NSilv]

This is a dealbreaker for us as well. We have a lot of enum values sitting around that we really don't want to change into tables for a lot of reasons. Lack of support basically means that we have to instead make endpoints (or alternatively actions) for each field that we want to update (we can read the enum values just fine, but we can't filter by them in where clauses, nor can we run mutations on them). Is there any chance this is getting implemented at some point?

[respectTheCode]

We moved on and built our graphql backend with Apollo Federation. It turned out to be a lot less work than we had expected and will be a better long term decision too.

[mnlbox]

Happy to see this is reopened again 😉
Really waiting for this feature.

[christian-predebon]

@respectTheCode @Fxlr8 Work on this issue has begun. Please expect it to land in one of the next two releases.

not to be rude but do we have any news today?

[christian-predebon]

nvm

[factoidforrest]

I'm just so confused why Hasura went to the trouble of implementing their "referenced table enums" before they tried to make native enums work. Graphql has enums, postgres has enums...as far as I can tell, they're almost a 1:1.

Yes, Enums should not be used for dynamic data. That doesn't mean you should NEVER use them and not support them.

Maybe this is an aside, but it feels similar to the lack of support for arrays, right down to having to insert arrays as psql formatted strings. Yes, arrays aren't always the right abstraction, but does that mean they should be totally unsupported and broken? Just because you've seen something abused doesn't mean it shouldn't exist.

[JuSacco]

Please consider adding this feature as at least as experimental.

[maxpain]

Any updates?

[ciphrd]

I find it concerning that after 5 years this hasn't been solved properly. As described by others, there are many good reasons to use native enums as opposed to single column tables, speed and storage optimisations being the main ones (there is a significant impact on tables with 1M+ rows, the different between having enums and string can turn into 100's of MBs of savings).

IMO an aggregator such as Hasura shouldn't take such opinionated design decisions on what are and what aren't good DB practices, especially when in this case all approaches have benefits.

The biggest impact of this decision for us is that our codegen tools don't type many of our enums at all, which impacts DX and code safety by a great margin (also prevents various type-safe design patterns of being implemented).

I think it would be great to add support for both cases.