Inherited computed fields

### Is your proposal related to a problem?

Hello guys, I'm working on integrating Hasura v2.38 with the Moodle database( running on PostgreSQL), I'm running into some issues here, I know this is probably not a bug and it's just that Hasura doesn't support this kind of functionality, I think it should.
So I'm trying to replicate the behavior of this [endpoint](https://doodlezucc.github.io/MoodleREST/#core_enrol_get_users_courses) which returns the list of courses a given user is enrolled in, for context this is an endpoint from the moodle web service REST API that allows querying the [moodle database](https://www.examulator.com/er/output/index.html), but the thing is this endpoint gets information from different tables, so adding a relationship between the [mdl_user](https://www.examulator.com/er/output/tables/user.html) table and [mdl_course](https://www.examulator.com/er/output/tables/course.html) table won't give access to all properties, which is why I figured I should use a computed field so that I can write the query that retrieves all the missing properties from mdl_course, and since the properties I want to return come from different tables, I need to create a table that has the return type of the computed field, and because the mdl_course table has 37 columns which I'm obviously not willing to write down even if I could(DRY), I used inheritance to do this:

```plpgsql
CREATE TABLE graphql.user_courses
(
completionhascriteria boolean,
completionusertracked boolean,
progress float,
completed boolean,
lastaccess bigint,
isfavourite boolean,
hidden boolean
)
INHERITS (public.mdl_course);
```

so basically it's a table that inherits from mdl_course and has the additional properties I want to add.
So now I can create a function to resolve all of these properties and it will return a SETOF user_courses, great!
But now comes the problem, there is one property left that exists in the endpoint and I don't have it yet, it's overviewfiles, thing is this is an array of objects that come from the [mdl_files](https://www.examulator.com/er/output/tables/files.html) table and so it needs its own computed field, the problem is that overview files only belong to courses and not to a user and a course at the same time( like progress is for example), which is why I thought I should add the computed field to the mdl_course table and not user_courses which makes sense, but that doesn't work, even if user_courses inherits from mdl_course, user_courses doesn't have access to the computed fields mdl_users have, that makes sense logical because computed fields exist on the level of Hasura and INHERITS is done by PostgreSQL and since Hasura works on top of the database, the database obviously won't tell Hasura to add the computed field to user_courses because it doesn't know, that makes sense, it could be fixed if maybe Hasura tracked all tables that inherit from a given table but that's a long shot and I think it's acceptable for Hasura to not do this, so this means that I should add the same computed field to user_courses, well here comes the real problem, I can't do that, because Hasura thinks the function that calculates overviewfiles takes in mdl_course and not user_courses, and even if user_courses inherits from mdl_course which means it has an identical copy of all of its properties, Hasura doesn't accept that function running on user_courses, so in addition to having to create two computed fields in different places that do the same thing which is, okay acceptable, I have to create two functions that do the same thing and the only difference between them is the input type( which is not really different), I think this is beyond slightly annoying and is a red flag that there is something wrong in the way Hasura works, it may sound silly that I'm not willing to write the same thing twice but I think it's not.

### Describe the solution you'd like

I think probably the best way to fix this model is to allow computed fields to be calculated from functions that can take as input/return types and not just tables, I know there is already an issue for this, @0x777 [explained](https://github.com/hasura/graphql-engine/issues/3865#issuecomment-585146793) why it is not simple to have this behavior, I understand that but I think you should think about fixing this even if it requires adding permissions to types/functions. I think Hasura will be much more powerful when this is solved.

Start by reviewing Hasura's computed-field behavior for PostgreSQL tables and the related discussion in issue 3865. Use the Moodle inheritance example and the requested function input and return types to define the supported behavior, then verify that inherited tables can expose the computed field without duplicate functions.

Written by the indexing model from the issue text.