add: configs as json GUC for db-root-spec

[taimoorzaeem]

Reopened #5085. Closes #3029.

[steve-chavez]

Approving but let's wait for @wolfgangwalther and @mkleczek to see if they have any concerns.

[wolfgangwalther]

I'll assume Michal's concerns in #5085 (comment) have not changed, since the PR's content has not changed.

My concerns were raised in #3029 (comment).

[steve-chavez]

@wolfgangwalther I guess then you're suggesting to throwaway unnamed parameter support from the root spec and special case it? As commented on #5085 (comment)

[wolfgangwalther]

I guess then you're suggesting to throwaway unnamed parameter support from the root spec and special case it?

No, I'm suggesting the magic named argument support added to all RPCs, including the root endpoint. We have discussed this at some point somewhere, but I don't know how to find it quickly. IIRC, the gist was:

• Because of filters, argument names to functions can not contain . anyway right now, I think. Even if they can, we could remove that functionality.
• Once a function has named arguments of the kind request.xxx or headers.yyy or config.zzz etc. (there will surely be more useful prefixes), PostgREST will pass those arguments without having to put them in the URI during the request.

That means if your root endpoint function needs to know the value of server_host, it will add a named argument config.server_host and voilà.

[steve-chavez]

Yeah that wasn't mentioned anywhere on #3029. Having it handy would have saved me a loot of time/effort 😿

the magic named argument support added to all RPCs

Sounds like there's some consistency to it but what would be the benefit for all non-root endpoint RPCs? We already have the request.headers GUCs and note that we cannot pass this as function parameter for pre-request and tables because it won't work for triggers. So we cannot make that consistent across the board.

That means if your root endpoint function needs to know the value of server_host, it will add a named argument config.server_host and voilà.

A simplification would be just a request.root.configs JSON parameter.

---

Also I guess now that we didn't decide to merge it for v16, maybe we should prefer to solve #4863 (comment); with that we could avoid the need to pass configs and we don't have to change anything here.

[wolfgangwalther]

Sounds like there's some consistency to it but what would be the benefit for all non-root endpoint RPCs? We already have the request.headers GUCs and note that we cannot pass this as function parameter for pre-request and tables because it won't work for triggers. So we cannot make that consistent across the board.

I think the original proposal was focused on the pre-request function and I don't see why it wouldn't work for that. My proposal was then to not set the GUCs anymore, but allow users to set GUCs in pre-request on their own, if they need these values in other places.

RPCs can then just take a shortcut here by naming these arguments themselves.

TLDR: This is supposed to replace the GUC stuff eventually.

[steve-chavez]

TLDR: This is supposed to replace the GUC stuff eventually.

It won't work for table endpoints as I've mentioned before, I've seen this type of use cases in the wild:

create trigger .. 
before insert on my_table
for each row
when (current_setting('request.method', true) = 'POST')
execute function ..;

Edit: overall GUCs are one of our strongest/stable parts, I don't see a reason to discuss moving away from them now when there are so many other issues.

[wolfgangwalther]

It won't work for table endpoints as I've mentioned before, I've seen this type of use cases in the wild:

That's why I mentioned that users can use arguments in pre-request and set their GUCs in there. Then it will work the same way.

overall GUCs are one of our strongest/stable parts, I don't see a reason to discuss moving away from them now when there are so many other issues.

Well, this was just in response to "why is this useful for RPCs?". We don't need to discuss this for RPCs - but no matter what, the named argument interface is much better for the root endpoint.