Revert "fix: handle queries on non-existing table gracefully"

[taimoorzaeem]

This reverts commit 390ba19.

Continues #4468.

[steve-chavez]

Helping with the test on #5121

[steve-chavez]

Looking at #3602, the solution for this should be in line with the new "schema cache as best effort", so I don't think we can look at the schema cache for table existence in every case.

So for #3602, the tables should only be looked at when they're part of resource embedding. If it's just a /tbl?select=..&id=eq.1 then that should not look into the schema cache and just go directly into the db, then map the pg error to 404.

[steve-chavez]

For #3697 it should be a similar logic, just let the request fail and go to the db if the insert doesn't use the more advanced features that require the schema cache.

[wolfgangwalther]

So for #3602, the tables should only be looked at when they're part of resource embedding. If it's just a /tbl?select=..&id=eq.1 then that should not look into the schema cache and just go directly into the db, then map the pg error to 404.

Can we really avoid looking at table/columns names in general (without resource embedding)? I don't think so, don't we need this to support domain representations as well?

[taimoorzaeem]

Can we really avoid looking at table/columns names in general (without resource embedding)? I don't think so, don't we need this to support domain representations as well?

Yes, I think we can avoid them in general. That's how it was before #3869, no?

If the table or column doesn't exist we'll get the error from pg, but if they do, then the domain representation is applied automatically by postgrest, right?

[wolfgangwalther]

If the table or column doesn't exist we'll get the error from pg, but if they do, then the domain representation is applied automatically by postgrest, right?

So, you are saying that:

• You create a new table with a domain representation, but don't reload the schema cache, yet.
• You make a first request and get a response without the domain representation applied.
• You reload the schema cache.
• You make a new request with a new response with the domain representation applied.

Right?

You will get two different responses for the same GET request, depending on whether the schema cache was reloaded or not. There was never an intention to return the values without the representation applied.

I don't think we should do this.

[taimoorzaeem]

• You create a new table with a domain representation, but don't reload the schema cache, yet.
• You make a first request and get a response without the domain representation applied.
• You reload the schema cache.
• You make a new request with a new response with the domain representation applied.

Right?

Ah, right right..

There was never an intention to return the values without the representation applied.

I see. So, it looks like schema cache reload is necessary to correctly support all table queries? If that's the case, then this dynamic table creation wouldn't work at all, meaning we can't revert this.

[steve-chavez]

If we cannot do this because of domain representations, maybe we should restrict their application somehow? Like they're only applied on some new Prefer value?

Because for #4613 (comment), all the huge amount of tables are on the same schema. So this cannot be solved by splitting the cache load somehow, like by schema.