Conditionally exclude fields from Query

[dvv]

Please consider adding an internal (exclude?) directive for any sort of fields. This should move the field out of Query/Mutation while keeping it available on deeper levels.

The default to be the scope's value.

This is mainly to housekeep the Query/Mutation clean while having all needed things in one exposed db schema.

[olirice]

As a rule we try to keep pg_graphql as configuration-free as possible

For excluding entities from insert/update/delete the best solution is to revoke insert/update/delete access from the relevant role.

I could see an argument for a comment directive to exclude it from the Query object though and it wouldn't be very invasive.

Will leave this open and mark as good first issue

[dvv]

Well, revoking access does disable operations at db low-level as well. One has no option to disable access via graphql layer only, nope?

[Dmo16]

Being able to exclude tables from the schema is a logical feature, IMO. As @dvv mentioned, it isn't really feasible to restrict permissions on a table to the point where we can't interact with it.

My current use case that ties into this is that I need to extend my schema in a way that pg_graphql does not currently support.

To achieve this, I'm writing a small microservice with an edge function and stitching the endpoints together.

It would be nice to exclude the relevant tables from the pg_graphql schema so that I can expose them through this microservice as a modular unit.

I can, of course, handle type dupes and such in the stitching, but that creates more work than needed if I could simply decorate the table in Postgres to tell pg_graphql not to include it in the schema.

[FelixZY]

In my case, I would like the user to be able to create entities and see the entity id field. However, I do not want users to be able to pick their own ids during creation/update. This would be much more explicit if I could remove the id field from the mutation type only.

[olirice]

@FelixZY for an id fields you can accomplish this by making that value a serial type or generated

in both of those cases the API excludes those fields from each table's insert and update types so your value is always generated by postgres rather than being provided by the user

I'll open an issue to add that info to the docs