[Feature Request] Provide information on possible embeddings

[LorenzHenk]

Description

As seen in #1625, you're putting a lot of effort into making resource embedding work for more and more queries.

As mentioned in #1179 (comment), It would be great to be able to access this information, i.e. having an endpoint to query PostgREST for the possible embeddings of a table / view.

Would it make sense to add this information to the / openapi endpoint?

Use case

A user can decide from a dropdown which embeddings he wants to use, we automatically build the select GET parameter based on the selected embeddings.
The possible embeddings to choose from come would come from this new endpoint.

[wolfgangwalther]

Thanks for opening that issue, good to be able to track that separately.

Would it make sense to add this information to the / openapi endpoint?

Yes, I think that's the best way to do it.

[steve-chavez]

On latest nightly we have a --dump-schema option that dumps the whole schema cache as plain json(not OpenAPI) - including all relationships. Perhaps we should make that accessible at runtime?

We could make it available by requesting a special header(maybe application/vnd.pgrst.schema+json) on root /.

[steve-chavez]

With the above, the root endpoint would output the full schema cache json with no filtering capabilities. To solve this we could use the db-root-spec function and pass the json as a parameter(as we discussed in #1698). Then the function could structure the json and make it filterable.

I propose this because it'd be a shorter term solution. Defining how we would represent relationships in OpenAPI might take some time(no standard, we'd need openapi extensions).

(Note: currently db-root-spec doesn't accept a schema qualifier, we also need this as mentioned in #1729 (comment)).

[LorenzHenk]

On latest nightly we have a --dump-schema option that dumps the whole schema cache as plain json(not OpenAPI) - including all relationships. Perhaps we should make that accessible at runtime?

We could make it available by requesting a special header(maybe application/vnd.pgrst.schema+json) on root

Sounds good. In our internal use-case (not the one mentioned in this issue), we prefer 1 endpoint for all relationship information over 1 endpoint per table / view, so this would fit our needs.

For completeness sake, the idea of exposing resource embedding metadata also already came up here: #1573 (comment)

[steve-chavez]

@LorenzHenk Check #1794. We're implementing this one there.