Update configuration page

[wolfgangwalther]

This is kind of a rework of the configuration page, including:

• Adding the missing db-root-spec config parameter
• Renaming the config parameters according to Rename config settings with fallback aliases postgrest#1679
• Sorting all config parameters alphabetically
• Adding names for environment variables and database settings for each parameter
• Re-organizing the whole page, so that the list of parameters is last (so that the environment and database sections come before the list, which already mentions the names for those settings)

[steve-chavez]

All LGTM!

Adding the missing db-root-spec config parameter

Hm, except this one. The db-root-spec idea is fraught with performance deficiencies, in fact the whole json generation for OpenAPI inside PostgREST is. I mentioned this before on PostgREST/postgrest#1794 (comment) and lately I've been finding instances where even a bigger schema results in postgrest consuming 100% CPU and not finishing while trying to respond to the root endpoint.

Seems postgrest-contrib will also be needed for performance and not just extensibility.

So it's likely that db-root-spec will be removed and it doesn't seem right to encourage users into relying on it, maybe not even in an experimental way.

How about not including in the docs?

[wolfgangwalther]

Adding the missing db-root-spec config parameter

Hm, except this one.
[...]
How about not including in the docs?

Ok, cool.

[wolfgangwalther]

The db-root-spec idea is fraught with performance deficiencies, in fact the whole json generation for OpenAPI inside PostgREST is. I mentioned this before on PostgREST/postgrest#1794 (comment) and lately I've been finding instances where even a bigger schema results in postgrest consuming 100% CPU and not finishing while trying to respond to the root endpoint.

Seems postgrest-contrib will also be needed for performance and not just extensibility.

So it's likely that db-root-spec will be removed and it doesn't seem right to encourage users into relying on it, maybe not even in an experimental way.

I understand the performance problem is related to the spec GUC (and the big OpenAPI query in core) right now - and not to the db-root-spec concept overall. So I guess db-root-spec will stay - although maybe the requirements for the function to be called might change. So it's good to keep it undocumented for now.