fix: in-db config values not loading for pgrst.server_trace_header and pgrst.server_cors_allowed_origins

[laurenceisla]

Closes #3345

[laurenceisla]

I tried using reReadConfig here, since it looks like the in-db configuration is not loaded:

postgrest/src/PostgREST/App.hs

Lines 70 to 74 in f1f01f1

	run :: AppState -> (Observation -> IO ()) -> IO ()
	run appState observer = do
	observer $ AppServerStartObs prettyVersion
	conf@AppConfig{..} <- AppState.getConfig appState

But after reloading the config the values will not update, since it will keep the old config values specified above.

---

Still, I'm not entirely sure if this is the best solution but it works in using the updated in-db configuration values.

[steve-chavez]

LGTM. Nice work 💯

[wolfgangwalther]

I still don't understand why we want to load server-xxx configs from the database at all. This still feels wrong to me, but I can't really articulate why.

[steve-chavez]

server-timing-enabled makes a lot of sense for instance. If you'd want to quickly get timings for a request. Changing that through the db is much quicker than through the config.

server_cors_allowed_origins and server-trace-header might not be that useful as in-db config. But I don't see why not.

IMO the only things that shouldn't are server-host, port, etc.. things that could bring down the postgREST service.

[wolfgangwalther]

Maybe it's also the other way around. Maybe I feel like the server- prefix is not correct for stuff that can actually be sensibly set via database configuration.

[steve-chavez]

Maybe I feel

Perhaps we can settle this with a shared design principle.

I'd like to pursue extreme-database centric architecture (pdf), which goes a bit beyond "db as source of truth". Right now:

• we're kinda db-centric (since we're two tier) but I'd like to get closer to the extreme part.
• we cannot do the server-host, server-port and others but there could be a future where we do.

For now following this principle for PostgREST means that everything should be configurable through the db. WDYT?

[wolfgangwalther]

For now following this principle for PostgREST means that everything should be configurable through the db. WDYT?

For the kubernetes-world, this would be a step backward. If you run PostgREST in a cluster, it should be configured via kubernetes, not the database.

[wolfgangwalther]

I think the original idea of database config was to put the config for things to the same place where a change would occur, which would make the config need to change. Examples:

• You need to change db-schemas, if you change your primary schema in the database. The change happens in the database, so the config option should be, too.
• You might need to change server-port, if you change things around your networking setup. This happens outside the database and has zero relevance for it.

Or to reframe it: When configuring PostgREST, I would like to theoretically point multiple instances of PostgREST, with possibly very different "outside" environments, at the same database with the same postgrest user. In this case, all the config that is the same, because it depends on database stuff, should be in the database. All the config that is about the environment that PostgREST runs in should be outside the database.