Running PostgREST with zero config

[wolfgangwalther]

Working on #1689, #1769, #1823 and #1991 here.

TODO:

• Add Changelog
• Add issue numbers to commit messages
• Add support to run without db-anon-role
• Change docs
• Add test for blocked anonymous request

[wolfgangwalther]

There are a few comments from the related issues, that are still open / to discuss:

we should print a warning when neither anonymous access nor JWT is set up

This is not the case right now.

I briefly thought about exiting with an error in that case... but since both config settings can be loaded from the database after a notify, I don't think we should do that.

This will allow to start postgrest, but disable any access while the database schema is being loaded into the database. At the end of the init script, the anon role and JWT secret can be set and a NOTIFY sent - and then postgrest will be functional.

We do have error messages for both anonymous requests and authenticated requests, when either the anon role or the secret is missing - so it will be pretty obvious what's happening.

Ideally we'd also show a warning saying that we're defaulting to the public schema and this might not be fit for production(with a link to our Schema Isolation docs).

This might be different... but then again I really hate warnings I receive when I do something like that and am perfectly fine with the default. The problem is then, that I can't disable the warning. Annoying.

But yeah, I guess that's still up for debate. Opinions?

[cemremengu]

I think these are all valid points.

I really hate warnings I receive when I do something like that and am perfectly fine with the default. The problem is then, that I can't disable the warning.

Maybe instead of warnings, postgrest can print info statements on startup stating what configuration it is being started up with. The interpretation will then be up to user whether it is a good or bad thing. However, I don't think this is a must since default functionality is already documented.

[wolfgangwalther]

Maybe instead of warnings, postgrest can print info statements on startup stating what configuration it is being started up with. The interpretation will then be up to user whether it is a good or bad thing.

I'd certainly like that much more. While messing with some of the io tests I also missed something like --dump-config for reloading. So maybe we can add a log level debug, that would basically print the config values whenever they are (re-)loaded: On startup, on NOTIFY, on SIGUSR etc.

Or, other idea: What if we add some kind of pgrst debug NOTIFY command, that just dumps the config and maybe some other internal state (think connection/pool stats...) on stdout? This could be handy when debugging running instances.

[cemremengu]

I think that would be a nice enhancement. Other platforms, if enabled, (like hibernate) also dump such debug statistics and information including raw sql queries generated by query builder.

[wolfgangwalther]

I think I broke the memory tests somehow. They are timing out now, not failing, so I didn't notice earlier. Will have to investigate.

[steve-chavez]

I'm missing this one(and the below export PGRST_DB_ANON_ROLE) because when doing:

postgrest-with-postgresql-13 postgrest-run

I can no longer make quick tests with the anon role. I can add PGRST_DB_ANON_ROLE=postgrest_test_anonymous but that's more inconvenient(no autocompletion).

@wolfgangwalther Can I add this back? What would be the drawback?

[wolfgangwalther]

Hm. I think the idea was to make the posgrest-with-postgresql-xx helpers more independent of the actual schema they are are loading. The files to load can be changed with -f, I think. And we do so for IO tests and loadtest.

I think I just forgot to add a db role setting in the spec schema for the anonymous role. The tests didn't fail, because the spec tests have a separate config for that anyway. But to be able to load the spec schema with postgrest-run it would be good to have that db setting.

And I'd go one step further: We should move the schema setting into the db config, too. No need to hardcode test here for all.