Graphql-engine: support custom SQL functions having composite type (rowtype) input arguments

[rakeshkky]

via https://github.com/hasura/graphql-engine/issues/3232#issuecomment-576796667

Tracking an SQL function which returns SETOF <table> and type of any one of input arguments is a table row (already tracked) gives the exception described in above referred comment. User creates such functions for computed fields and tracks them as custom SQL functions.

Solution:-

1. Allow table row type as scalars for function arguments in "args" input field. The name of such scalar types will conflict with the names of object types generated for the table. The possible solution I think as of now is to append _input for scalars generated for composite types. Input value for those row type scalars can be constructed as String literals (See Postgres docs).
   ~2. The "args" input for computed field should be named as <table>_<computed-field-name>_input_args and not <function-name>_input_args~ We can't change the generated type name as it breaks the schema. So, we can support solution 1 by restricting tracking an SQL function as either a custom SQL function (in queries) or a computed field of a table but not both.

• [ ] Update docs with appropriate example

[nicuveo]

This also happens for SQL functions that return a scalar, FWIW.

[charmpitz]

Any ideas when will this be solved? I'm stuck and it's really disappointing..

[beerose]

Related issue: https://github.com/hasura/graphql-engine/issues/5514

When a function with an argument being a table row is tracked, then introspection query is successful. However, using its result with graphql-js library to build a schema definition for graphiql explorer results in an error.

Example function:

CREATE FUNCTION sample_function(arg text_result) RETURNS SETOF text_result LANGUAGE sql STABLE AS $ function $
SELECT
  q.*
FROM
  (...) q $ function $

Error from graphql-js:

[altitudems]

Please prioritize this bug, it is preventing us from using computed fields. The only work around currently is to not track the postgres function, and leave the custom field. Not ideal, but at least we aren't totally stuck. Thanks so much for working on this!

[jberryman]

Post-PDV it seems that what happens is an error is thrown in collectTypes when trying to track a function that takes a table/composite-type argument (I haven't traced the error yet), so at least it's not possible to track such a function and get into a weird situation where the schema breaks