Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, and Storage.

Supabase

I know there's auth.uid() available in rls policies, but I'm using discord. is there a way to access `supabase.auth.user().identities[0].identity_data.provider_id` within an RLS policy?

Hello <@877301755858288670>!
This thread has been automatically created from your message in <#843999948717555735> a few seconds ago.

We have already mentioned the <@&951828363943759883> so that they can see your message and help you as soon as possible!

**Want to unsubscribe from this thread?**
Right-click the thread in Discord (or use the ``...`` menu) and select "Leave Thread" to unsubscribe from future updates.

**Want to change the title?**
Use the ``/title`` command!

**We have solved your problem?**
Click the button below to archive it.

This is the function for auth.uid():

```
create or replace function auth.uid() returns uuid as $$
  select nullif(current_setting('request.jwt.claim.sub', true), '')::uuid;
$$ language sql stable;
```
so you'd have to look to see if provider_id is saved in the jwt (I don't think it is)...
If it's not, you'd have to do a lookup on the auth.identities table, which won't scale well, but it's doable.

of course it depends on the app, but is doing a lookup each time really bad or fine unless there are hundreds of users (it'll be fine for my mvp i guess?)

Yes for an mvp it's fine, and fine if it's only used infrequently.

But let's say you put something like this on a table, then select 100 rows from that table.  It's gonna run 100 times just for that one select.

That's the scaling problem I'm talking about.

so better to find a more efficient way to do things

I think if you put your lookup in a "stable" function like the one above then you will only do one lookup no matter how many rows you search.  That assumes you are looking up the provider_id for the user making the call using their auth.uid() so that will never change during the RLS for this operation for each row processed.