Refactor Supabase plugin to avoid upsert operations to play better with RLS policies

[warrenbhw]

The PostgREST upsert endpoint (used by the supabase-js upsert function) interacts weirdly with some RLS policies.

Here's a simplified example of where things can go wrong:

I have a table notes with these columns:

• id: uuid
• content: text
• workspace_id: uuid
• deleted: boolean

I have an RLS policy that looks like this:

-- allow workspace members to select, insert, update, delete notes
create policy "Allow CRUD for workspace members" on public.notes
as permissive for all to authenticated
using ((workspace_id IN
    ( SELECT public.current_user_workspaces() AS current_user_workspaces)
))
with check ((workspace_id IN 
    ( SELECT public.current_user_workspaces() AS current_user_workspaces)
)));

if I do an upsert with this body:

{
  "id": "my-note-uuid",
  "deleted": true,
}

The RLS policy will fail, presumably because the logic in PostgREST leads to an attempt to check that the request meets RLS policy for both create AND update. This request doesn't pass the create branch of the check, because there is no workspace_id provided in the request.

The postgres plugin handles updates fine, because in that case, we send the entire record when we call upsert. However, on soft-deletes, we only send the id field and the deleted field, leading to this issue.

The two possible solutions are sending the entire record on delete, or splitting out creates and updates.

This seemed the cleaner and less error-prone avenue.

[warrenbhw]

cc @jmeistrich - lmk your thoughts here. Should be a quick review, if you're on board with this.

[jmeistrich]

@warrenbhw Yes, that looks perfect. I wasn't aware of that detail of RLS policies, very interesting! This is exactly the perfect fix, thank you!

Just one thing: the changes include bun.lockb which shouldn't have needed to change. Maybe it's just a difference in bun versions or something... I diffed them and it seems unchanged? But can you remove that file from the PR just to be safe?

[warrenbhw]

@jmeistrich sure, will do

[warrenbhw]

@warrenbhw Yes, that looks perfect. I wasn't aware of that detail of RLS policies, very interesting! This is exactly the perfect fix, thank you!

Just one thing: the changes include bun.lockb which shouldn't have needed to change. Maybe it's just a difference in bun versions or something... I diffed them and it seems unchanged? But can you remove that file from the PR just to be safe?

@jmeistrich lockfile change reverted. Mind approving the workflow and approving the PR? would love to land this today so I can start using it :)

[jmeistrich]

@warrenbhw Released in alpha.25

[warrenbhw]

sweet, thanks!