feat: add filters to pg_changes#1922
Conversation
filipecabaco
changed the title
|
coverage: 91.461% (-0.2%) from 91.62% — feat/pg-changes-added-filters-real-832 into main |
| {:error, %Postgrex.Error{postgres: %{code: :raise_exception, message: msg}}} -> | ||
| log_error("SubscriptionFatalError", msg) | ||
|
|
||
| for {pid, _id, _ref, _node} <- :ets.tab2list(subscribers_pids_table) do | ||
| send(pid, {:subscription_fatal_error, msg}) | ||
| end | ||
|
|
||
| {:noreply, state} |
There was a problem hiding this comment.
Could you explain why we need this? Is it related to filters?
There was a problem hiding this comment.
handling unknown filters to prevent the user from connecting
There was a problem hiding this comment.
So SubscriptionFatalError is missing in ERROR_CODES.md :)
leandrocp
left a comment
leandrocp
left a comment
There was a problem hiding this comment.
Just minor things, but interesting features!
To resolve the conflict on tenant_db_baseline.json just commit whatever and CI will regenerate it.
There was a problem hiding this comment.
It would be interesting to add a topic in README linking to this doc, useful for humans and helps AI to discover it too.
There was a problem hiding this comment.
will create a sort of index in README
|
|
||
| | Key | Type | Description | | ||
| |-----|------|-------------| | ||
| | `key` | string | Custom key to identify this client's presence entry. Defaults to a generated UUID. | |
There was a problem hiding this comment.
Since v4 is more popular it might be worth noting it generates v1
| | `key` | string | Custom key to identify this client's presence entry. Defaults to a generated UUID. | | |
| | `key` | string | Custom key to identify this client's presence entry. Defaults to a generated UUID v1. | |
| - Runs `realtime.is_visible_through_filters()` to match the row against each subscription's filters. | ||
| 5. Matching subscription IDs are returned alongside the change and dispatched to the appropriate clients. | ||
|
|
||
| ### Subscription parameters |
There was a problem hiding this comment.
wasn't there yet but will do
| | `like` | `LIKE` | Column matches pattern (case-sensitive). | | ||
| | `ilike` | `ILIKE` | Column matches pattern (case-insensitive). | | ||
| | `not_like` | `NOT LIKE` | Column does not match pattern (case-sensitive). | | ||
| | `not_ilike` | `NOT ILIKE` | Column does not match pattern (case-insensitive). | |
There was a problem hiding this comment.
Is this documenting realtime.equality_op or the public filter operators? I was expecting to see not.{...} in this doc 🤔
There was a problem hiding this comment.
not is a weird one as can only "not" on certain ops...
| begin | ||
| -- IS / IS NOT require keyword RHS, not a typed literal | ||
| if op = 'is' or op = 'not_is' then | ||
| if val_2 not in ('null', 'true', 'false', 'unknown') then |
There was a problem hiding this comment.
Two comments here:
-
PostgREST supports
not_nullas valid value forINoperator as well, I think we could easily support that one too. -
Value in PostgREST is case-insensitive (null, NULL, etc). Should we adhere to the same behaviour?
There was a problem hiding this comment.
yes we should will take that into account
Co-authored-by: Leandro Pereira <leandro@leandro.io>
…like_is_not_ops_to_filters.ex Co-authored-by: Leandro Pereira <leandro@leandro.io>
4 participants
What kind of change does this PR introduce?
add filters to pg_changes:
likeLIKEilikeILIKEnot_likeNOT LIKEnot_ilikeNOT ILIKEisISnull,true,false,unknownnot_isIS NOTnull,true,false,unknown