Add underscore equality operator to filter using keys in the request body

[laurenceisla]

WIP - Needs more discussion

---

Using this idea #2125 (comment), the underscore operators will filter using the keys in the body. This PR implements the following:

• The _eq operator to verify for equality with items in the body
• Support to select any identifier in the body (not only PKs). This gives more freedom in the case of bulk updates, e.g.:

  PATCH /user?is_active=_eq.is_active HTTP/1.1
  
  [
    { "username": "userA", "is_active": true },
    { "username": "userB", "is_active": false }
  ]

• Full table updates are allowed once again, addressing this issue: Add limited UPDATE/DELETE(tables only) #2195 (comment)

[steve-chavez]

I think it's fine to have _eq as a special case for now, we can add underscore versions of the other operators later.

One question though, will this work for DELETE and RPC as well?

[laurenceisla]

It does not work for DELETE in the PR because the body is ignored, but it should work with the changes in #2355 (unless those changes are done here to avoid breaking changes in the future).

RPC are a different story in which the filter of the result set is done outside of the pgrst_source CTE in the QueryBuilder.hs file, so it won't work out of the box unless the filter is done inside the CTE (may break some things). The resulting query looks something like:

WITH pgrst_source AS (
  WITH pgrst_payload AS (...).
            pgrst_body AS (...),
            pgrst_args AS (...)
           SELECT ... -- The WHERE should be done here for the filter to get the data from pgrst_body
)
SELECT ...
FROM
  (SELECT "table".*
   FROM "pgrst_source" AS "table"
   WHERE "table"."id" = "pgrst_recordset_body"."id") _postgrest_t  -- it is done outside instead, which gives an error

[wolfgangwalther]

Wait, the comment in #2125 (comment) says:

Underscore operators could be used to operate on columns besides referencing values on the request body. This would allow doing #1105 (comment) without computed columns:

SEARCH /PredictedGenes?Strand=eq.+&GeneStart=_gt.GeneEnd

Operating on a body value would still be allowed, body would be a reserved identifier:

SEARCH /PredictedGenes?Strand=_eq.body->strand&GeneStart=_lt.GeneEnd
{ "Strand": "-"}

With the implementation in this PR, the ability to do column to column matches will be lost, right?

[laurenceisla]

With the implementation in this PR, the ability to do column to column matches will be lost, right?

Yes. It was one of the reasons I turned this into a draft for now. It should use a syntax like ?col=_eq.$.col to get filters from the body and allow column matches too.