Support URL config value

[steve-chavez]

Hey there.

Adding support for getting a config value from a URL would allow us to close PostgREST/postgrest#1130 and PostgREST/postgrest#1292.

This would be similar to what dhall does: https://docs.dhall-lang.org/tutorials/Language-Tour.html?highlight=url#url-imports. I was thinking that maybe the {http/https}:// prefix could be inferred to be an HTTP value.

db-schema = "test"
jwks = https://domain.co/jwk ## without quotes

What do you think?

[steve-chavez]

Oh, I forgot about the import directive. So maybe it could be like this instead:

db-schema = "test"
jwks = import https://domain.co/jwk

[robx]

I don't really think this is a good idea, on several different levels...

1. There's my general feeling that this package is a bit of a poorly designed mess that I don't want to do feature development for. (The recent parsing error change was different in the sense that it made the package do what it does slightly less badly.)

2. I'm not really sure something like this belongs in a configuration file format. If this is really needed for postgrest, I'd prefer an approach where

   • postgrest would handle the http request itself
   • the API of this package would be adapted as necessary to make it easy to integrate that

   As a related approach, I could expose the low-level parser (Data.Configurator.Syntax), and we could move the interpretation layer over into postgrest itself. Then interpretation of the import directive would be up to postgrest, and this feature could be developed there. If you 'd like this, I'd be happy to make that change.

3. Would this even address the issue? As far as I understand, the potential users are serving a JSON file somewhere which they'd like integrated into their config, but configurator-pg would expect a file in its own format.

[steve-chavez]

There's my general feeling that this package is a bit of a poorly designed mess that I don't want to do feature development for.

Totally understand. No change needed from configurator-pg.

I think now this should be handled in postgrest. Similarly to what we do for an option = @filename config value.(I somehow thought this was handled in configurator-pg, sorry about that).