> about metadata: in Postgrest ..

We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the number of tables in information_schema/pg_catalog if we were to auto load all these. There is also the issue that you may not want to expose some tables. We can definitely have a console button which will let you import all the tables in public schema.

Sure, you can infer relationships from the foreign key constraints. But, how would you come up with names that do not conflict with the existing columns? What if you add a new column with the same name as an inferred relationship? With the data service, you can also define relationships on/to views across schemas (1). Making metadata explicit goes with one of our core principles, 'no magic'.

> what postgrest does for protection: a - no fancy joins,

explicit joins are not allowed even with our data service. The joins that happen are the implicit ones because of the relationships. We do the same thing if we need any custom joins/aggregations. Define a view and expose it.

> b - you can't do anything other than selecting columns and relationships with the api.

> c - the permission layer can be used to prevent these to some extent (like not allowing an anonymous user to filter on a particular column).

1. https://hasura.io/_docs/platform/0.6/getting-started/5-data-...