fix: Allow options to generate certain HTTP methods for a DB view

[laurenceisla]

WIP. It will resolve issue #1647.

My approach is to check first if the role has the permissions assigned to the DB table/view, only then check if it's insertable, etc.

[wolfgangwalther]

Nice work, I like it! :)

[steve-chavez]

@laurenceisla The Allow header is looking good 👍. However, I think we're missing something. I've just tried this:

http POST localhost:3000/projects_view_with_delete_trigger <<JSON
{"id": 6, "name": "client 6"}
JSON

HTTP/1.1 500 Internal Server Error
Content-Type: application/json; charset=utf-8

{
    "code": "55000",
    "details": "Views containing DISTINCT are not automatically updatable.",
    "hint": "To enable inserting into the view, provide an INSTEAD OF INSERT trigger or an unconditional ON INSERT DO INSTEAD rule.",
    "message": "cannot insert into view \"projects_view_with_delete_trigger\""
}

According to the RFC, we should reply with a 405 Method Not Allowed instead.

If we do this, the client request wouldn't not reach the db. The disadvantage I see is that if users add a INSTEAD OF INSERT trigger, they'll need to refresh our schema cache to make the request succeed.

WDYT? Shall we do this?

Edit:

I was thinking that perhaps we can just catch the 55000(object_not_in_prerequisite_state) error and convert it to a 405 Method Not Allowed, but seems this code is used for other internal errors as well.

[wolfgangwalther]

According to the RFC, we should reply with a 405 Method Not Allowed instead.

If we do this, the client request wouldn't not reach the db. The disadvantage I see is that if users add a INSTEAD OF INSERT trigger, they'll need to refresh our schema cache to make the request succeed.

WDYT? Shall we do this?

Edit:

I was thinking that perhaps we can just catch the 55000(object_not_in_prerequisite_state) error and convert it to a 405 Method Not Allowed, but seems this code is used for other internal errors as well.

Ah, an easy way out would have been cool. But given that this seems not possible to do, I think this will be out of scope for this PR, as discussed here:

• fix: Allow options to generate certain HTTP methods for a DB view #1824 (comment)
• fix: Allow options to generate certain HTTP methods for a DB view #1824 (comment)

[steve-chavez]

But given that this seems not possible to do, I think this will be out of scope for this PR, as discussed here

Cool. I do think that anything that makes PostgREST less transparent to the db requires more discussion anyway. So lets leave that for another time.