Open psteinroe opened 1 week ago
Both schemas need to be in db-schemas
:
db-schemas = "api,public"
Then, the request would be:
curl 'localhost:3000/one?select=name,list:two(name)'
My expectation is that postgrest prefers the table in the primary schema.
I would expect so too. I had my doubts since PostgREST allows embedding through views and thought that maybe this is detecting public.one-two
and api.one-two
as possible intermediate embeds. But then I tried dropping the api.one_two
view, this would mean that public.one-two
is the only candidate to embed between api.one
and api.two
. As expected it recognized it, but it returned a SQL error:
{
"code": "42P01",
"details": null,
"hint": "There is an entry for table \"one_two\", but it cannot be referenced from this part of the query.",
"message": "invalid reference to FROM-clause entry for table \"one_two\""
}
So, there's definitely something wrong with a) the embedding detection or b) with building the query. I believe that it's both so I'm tagging this one as a bug for now.
For now, you can disambiguate the many-to-many relationships using spread embeds. So, the request would be:
curl 'localhost:3000/one?select=name,list:one_two(...two(name))'
Or, I'm assuming it's like this in supabase-js
:
const { data, error } = await s.from("one").select("name,list:one_two(...two(name))");
Thanks for the quick response!
Our use case is that the api schema will serve as our public api, and changing all queries in our app that target the public schema is not an option.
Let me know if I can support here further.
Environment
Description of issue
A Postgrest many-to-many query fails if a table in the "primary" schema has the same name as a view in another schema also exposed by postgrest.
My expectation is that postgrest prefers the table in the primary schema. Note that explicitly setting the db schema on the supabase client also does not change anything.
Reproduction: https://github.com/psteinroe/postgrest-repro
Schema:
The query (using supabase-js):