feat(postgrest, supabase): add useSchema() method for making rest API calls on custom schema.

[dshukertjr]

What kind of change does this PR introduce?

Allows developers to easily query custom schema.
Fixes #314

What is the current behavior?

There isn't a way to query other schemas once Supabase client is initialized. Some workarounds that I can think about right now would be

• Don't use custom schemas
• Create postgres views/ functions in the public schema for every custom schema table
• dispose and re-initialize the client every time when querying custom schema
  All of them are kind of painful to implement.

What is the new behavior?

Developers can query custom schema like this:

final data = await supabase.useSchema('custom_schema').from('table').select();

Additional Context

Since schema name is already taken, we couldn't name the method schema() like how the js SDK does it.

[Vinzent03]

Is there a reason you are adding that as a parameter to from instead of a new method as it seems proposed in supabase/postgrest-js#280 ?

Additionally, I think rpc needs that param as well.

[dshukertjr]

@Vinzent03 No, I had forgotten about that one. Thanks for bringing it up.

[Vinzent03]

.setSchema() sounds like you would change the schema of the existing postgrest client. What about just .schema(). That's what they use in js now as well.

[dshukertjr]

@Vinzent03
I should have mentioned it in the PR somewhere, but the schema name is already taken by the schema property of SupabaseClient and the PostgrestClient, so had to go with something else. In the next major release though, we should be able to rename it to schema() after making the schema property private.

Also would love to hear your thoughts on the method name. Some that went through my head were:

• setSchema()
• useSchema()
• fromSchema()

[Vinzent03]

Ah okay. I would choose useSchema() or fromSchema(). I tend towards fromSchema(), because it's similar to from() and that's okay, because they both do pretty much the same.

[bdlukaa]

I like useSchema better. setSchema can be misleading

[dshukertjr]

Thanks for the comments. It was very close for me between setSchema() and useSchema() for me, so I'd say useSchema() is the winner. Also want to hear your opinion on another thing. What do you think about a syntax like this:

.from('table', schema: 'my_schema')

which is what I had originally on this PR. I know it's not at all similar to the js implementation, but I think it's cleaner, because we don't have extra words like use or set with the schema keyword. I also slightly don't like the fact that you can chain useSchema like this:

supabase.useSchema('my_schema').useSchema('another_schema')...

It means the IDE will suggest useSchema() after calling useSchema like this.

[Vinzent03]

Using the current workflow allows using one postgrest client with a specific schema for multiple calls. Adding it to from means you have to repeat it always. So I would stay with the current approach.

[dshukertjr]

Cool, in that case this PR should be ready for review.

[garysm]

@dshukertjr Can you give an example of what the recommended permissions should be for a new schema for the Flutter client? For example, a table that would only be available to postgres, service_role, and authenticated users. I have tried adding these myself but I still get a PGRST106 error.

[dshukertjr]

@garysm
Have you added your new schema to search path in your Supabase dashboard under settings>API>Extra Search Path?

[garysm]

@garysm Have you added your new schema to search path in your Supabase dashboard under settings>API>Extra Search Path?

No, I've been developing locally, but I assume that can be configured in config.toml. I'll give that a shot. Thanks!