Enable filters for delete events

[w3b6x9]

Feature request

Is your feature request related to a problem? Please describe.

I want to be able to filter delete events based on primary key(s) and when replica identity is set to full, filter based on all columns available in database table.

Describe the solution you'd like

For DELETE events:

• when I want to filter by a column that is not available in old_columns, then the subscriber is ignored.
• when replica identity is not full, only filters referencing the pk column(s) are respected.
• when replica identity is full, filters referencing any column in the table are respected.

Additional context

• See comment: Realtime + RLS not working @ hosted supabase cloud realtime#265 (comment)

[roobox]

I am really desperately waiting for this feature!

[Zeulni]

Stumped upon that, need the same feature for my team!

[christophemenager]

Thanks for opening this issue @w3b6x9.

This should be at least clearly documented, it created a major in production for my mobile app...

[andy-leezard]

Hello, are we getting any official fix on this matter soon?

[w3b6x9]

This should be at least clearly documented, it created a major in production for my mobile app...

@christophemenager great call, i'll let our Realtime team know and we'll add it to our docs.

[gsw85]

The UPDATE event ignoring filter as well

[Stiffjobs]

The UPDATE event ignoring filter as well

Mine is working on UPDATE event

[georgii-ivanov]

Can we just filter by old record ID? So we know it, just implementing that filter would be helpful

[alexeigs]

It basically means you can't listen to the deletion of any user records currently because you'd subscribe to all deletion events on this table across the entire user base, right?

I hope there's a fix or a recommended workaround added to the documentation given it's a major challenge everyone using realtime capabilities may face.

[cphoover]

I really think that the limitations to realtime... such as this... such as the limitations on filtering multiple columns... such as the scaling issues related to listening to postgres_changes... should preclude supabase from being marketed as a realtime db...

These limitations really make using subscriptions to db changes useless for most real world applications.

I understand you can have a server that consumes postgres_changes and then emits with broadcast... but ideally these features would exist baked into the framework without having to host an additional server layer.

[upnorth]

FYI. I solved this with a workaround. I made a pretty unique key (to avoid conflicts with user data) for deletes that my app can look for and ignore, and just trigger changes to the local state with. So my users can add stuff which then gets propagated to all sessions, but if they want to clear the state, I send both a delete command and an insert command after. delete nukes the user content in the db, and the insert triggers a subscription event to all sessions to clear the local state. Kind of messy, but it works. Depending on your use-cases it might be enough so you don't have to switch to an entirely new solution until Supabase figured this out?

EDIT: Just noticed that this was specifically for filters. But I didn't get any delete events at all when I debugged my app, so hence my workaround. Hopefully it can still be useful to someone.