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: https://github.com/supabase/realtime/issues/265#issuecomment-1223768129

[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.