Laurence Isla

Maybe the function is being created in the `public` schema by default. Try specifying the `basic_auth` schema instead: ```sql create or replace function basic_auth.login(email text, pass text) returns basic_auth.jwt_token --...

This was my take of the issue: > From my POV I see it more using a PostgreSQL perspective. Also, this was allowed even before the computed relationships were implemented....

I'm reopening this because I think that turning the string to an empty array instead of failing may cause confusion when there's a mistake in sending a JSON object with...

Reopened, now that is #2424 is merged.

There are two options we could go for: 1. Dissallow the usage of scalar functions that `returns ` for computed relationships 2. Fix it and return only a `to-one` relationship....

Wow, very nice and thorough investigation! Maybe this will turn too big for a single issue, I'll open new ones if required. First, let's address the issues you mentioned. ---...

> I see that taking a set-returning function as a computed column is acceptable, but the result is still unexpected (to me). Intuitively (and conventionally with PostgREST), a query with...

I cannot reproduce the inconsistency in the responses, maybe it has to do with the size of the db? But still, there's a difference between the foreign keys in `v1`...

Just to give an example to hide the `access-control-allow-origin` header using https://github.com/PostgREST/postgrest/issues/2441#issuecomment-1229217627: ```nginx server { # ... location /api/ { default_type application/json; proxy_hide_header Content-Location; add_header Content-Location /api/$upstream_http_content_location; proxy_set_header Connection "";...

Btw, here are the steps to reproduce this: https://github.com/PostgREST/postgrest/issues/2443#issue-1346175376