supabase / pg_graphql

GraphQL support for PostgreSQL
https://supabase.github.io/pg_graphql
Apache License 2.0
2.9k stars 103 forks source link

Extend computed fields with additional parameters #295

Open dvv opened 1 year ago

dvv commented 1 year ago

Summary

To allow

create or replace function app._last_events(app.project, count int) returns ...

to be natively used like

query GetProjects {
  projectCollection {
    edges { node { id code name lastEvents(count: 1) } }
  }
}

Rationale

To allow for a richer computed fields resolution logic.

Design

We already analyze computed field functions signatures to insert them into the schema. I believe we could as well detect function argument name and type and auto-add schema input fields for additional arguments.

Drawbacks

Don't see any.

Alternatives

Certainly we can pass additional info down to computed field resolver via global variables by doing

set_config('graphql.vars', $1->>'variables', true)

in app.graphql() and using

coalesce(current_setting('graphql.vars', true)::jsonb->>'count', '1')::int

in the computed field function.

The above is just a lot of hackish plus it pushes to pass data beside the schema and bypasses input validation.

olirice commented 1 year ago

it isn't currently possible to have additional parameters using the computed column feature. This feature is related to #222 but lets track it separately here as it'll probably be implemented in a separate PR

dvv commented 11 months ago

@olirice I managed to generate correct (hopefully) schema fields for the subj here https://github.com/dvv/pg_graphql/blob/master/src/graphql.rs#L2028-L2060.

create or replace function app._roles(app.user, i int = 123, s text = '456') returns text[] stable return array[s]::text[];
roles(i: Int = 123, s: String = "456"): [String]

Then I issue

query profile {
  theUser {
    id
    username
    roles(i: 222, s: "111")
  }
}

but the app._roles() is given only the first argument.

Please point out where to look for passing other arguments?

olirice commented 10 months ago

Please hold off on this feature. We need to make some decisions internally about how to differentiate between functions which extend base types and functions that are on the Query object and that'll have a significant impact on implementation

PhilippS93 commented 4 months ago

any progress with this feature?

olirice commented 4 months ago

Not yet. We've been focusing on extending filtering options and upsert support