pg_graphql
pg_graphql copied to clipboard
supabase
Support name overrides for enum variants
If a postgres enum variant is not a valid graphql name, loading the schema results in
{
"errors": [
{"message": "Names must only contain [_a-zA-z0-9 but <invalid name> does not"}
]
}
for example, any enum variant containing a space will fail
none yet. The hesitation is that there is no way to comment on an enum variant which means we'll have to introduce a data structure on the enum type that contains a mapping
if the enum is not needed by your schema, revoking select from authenticated and anon will allow the schema to load.
If you do need the the enum in your schema, updating the variants to conform to _a-zA-z0-9 is currently the only workaround
Just came across this as well.
Due to the limitation on the GraphQL spec side for "values" of an enum, but no such restriction on the PostgreSQL side, there needs to be a way in pg_graphql to deal with it.
It would be great if there was a way to "tell" pg_graphql: for this enum, please use these (immutable) in/out functions, so that a direct conversion can still happen.
The main issue here is that enums have to be convertible in and out losslessly, therefore strategies like replacing disallowed characters with, say, underscore won't work.
What if pg_graphql read comments for the enum type (JSON) with optional mappings something like this:
comment on type my_enum is E'@graphql({"variants": {"valid value": "valid_value"}})';
Variants that are valid in GraphQL don't need to be listed in the comment.
Variant names are required to be unique on both ends, we can use the same map inverted when translating to Postgres.
@yrashk That may work if you just have a handful of values that are affected. In my case, I have potentially hundreds, which is why I would vote for functions instead of static comment mappings. That would allow querying mapping tables (if "stable" was allowed) or use deterministic, application-specific value conversions to achieve the desired results.
From my perspective, simply the fact that pg_graphql tries to directly map a PostgreSQL enum into a GraphQL enum without any value checks is very unfortunate, since that directly breaks it. So even if you had "compliant" enum values so far, just introducing a new one with a DB migration will break the API instantaneously.
Great point. Just wondering if, instead of executing function at runtime, the function was used to generate the mapping when the type is updated. Would that be ok or worse?
Granted, this makes it a bit trickier to install, but maybe (need to check, away from my computer right now) direct pg_description manipulation or, worst case, query construction in plpgsql.
This way, a definite mapping can be generated.
I'm just feeling a bit uneasy to call one or more of these functions to generate a name at runtime, as opposed to having a preloaded context as it stands now.
Just how large do your enums get?
To expand on this further, we don't really need to rely on comments to attach metadata, we can store it elsewhere.
@yrashk Some of my enums are maintained from external data, periodically updated and appropriate migrations generated, so I don't even have much influence on the naming since their values (from that external data source) are relied on in other tables and also by consumers of the service.
I currently have 4 enums with more than 100 entries (largest currently holding 8000+ entries, but this specific one is safe).