|
| 1 | +# Supabase |
| 2 | + |
| 3 | + |
| 4 | +## No operators, no problems |
| 5 | + |
| 6 | +Supabase [does not currently support](https://github.com/supabase/supautils/issues/72) custom operators. |
| 7 | +The EQL operator functions can be used in this situation. |
| 8 | + |
| 9 | +In EQL, PostgreSQL operators are an alias for a function, so the implementation and behaviour remains the same across operators and functions. |
| 10 | + |
| 11 | +| Operator | Function | Example | |
| 12 | +| -------- | -------------------------------------------------- | ----------------------------------------------------------------- | |
| 13 | +| `=` | `eql_v1.eq(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.eq(encrypted_email, $1)`<br> | |
| 14 | +| `<>` | `eql_v1.neq(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.neq(encrypted_email, $1)`<br> | |
| 15 | +| `<` | `eql_v1.lt(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.lt(encrypted_email, $1)`<br> | |
| 16 | +| `<=` | `eql_v1.lte(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.lte(encrypted_email, $1)`<br> | |
| 17 | +| `>` | `eql_v1.gt(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.gt(encrypted_email, $1)`<br> | |
| 18 | +| `>=` | `eql_v1.gte(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.gte(encrypted_email, $1)`<br> | |
| 19 | +| `~~` | `eql_v1.like(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.like(encrypted_email, $1)`<br> | |
| 20 | +| `~~*` | `eql_v1.ilike(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.ilike(encrypted_email, $1)`<br> | |
| 21 | +| `LIKE` | `eql_v1.like(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.like(encrypted_email, $1)`<br> | |
| 22 | +| `ILIKE` | `eql_v1.ilike(eql_v1_encrypted, eql_v1_encrypted)` | `SELECT * FROM users WHERE eql_v1.ilike(encrypted_email, $1)`<br> | |
| 23 | + |
| 24 | +### Example SQL Statements |
| 25 | + |
| 26 | +#### Equality `=` |
| 27 | + |
| 28 | + |
| 29 | +**Operator** |
| 30 | +```sql |
| 31 | +SELECT * FROM users WHERE encrypted_email = $1 |
| 32 | +``` |
| 33 | + |
| 34 | +**Function** |
| 35 | +```sql |
| 36 | +SELECT * FROM users WHERE eql_v1.eq(encrypted_email, $1) |
| 37 | +``` |
| 38 | + |
| 39 | + |
| 40 | +#### Like & ILIKE `~~, ~~*` |
| 41 | + |
| 42 | + |
| 43 | +**Operator** |
| 44 | +```sql |
| 45 | +SELECT * FROM users WHERE encrypted_email LIKE $1 |
| 46 | +``` |
| 47 | + |
| 48 | +**Function** |
| 49 | +```sql |
| 50 | +SELECT * FROM users WHERE eql_v1.like(encrypted_email, $1) |
| 51 | +``` |
| 52 | + |
| 53 | +#### Case Sensitivity |
| 54 | + |
| 55 | +The EQL `eql_v1.like` and `eql_v1.ilike` functions are equivalent. |
| 56 | + |
| 57 | +The behaviour of EQL's encrypted `LIKE` operators is slightly different to the behaviour of PostgreSQL's `LIKE` operator. |
| 58 | +In EQL, the `LIKE` operator can be used on `match` indexes. |
| 59 | +Case sensitivity is determined by the [index term configuration](./docs/reference/INDEX.md#options-for-match-indexes-opts) of `match` indexes. |
| 60 | +A `match` index term can be configured to enable case sensitive searches with token filters (for example, `downcase` and `upcase`). |
| 61 | +The data is encrypted based on the index term configuration. |
| 62 | +The `LIKE` operation is always the same, even if the data is tokenised differently. |
| 63 | +The different operators are kept to preserve the semantics of SQL statements in client applications. |
| 64 | + |
| 65 | +### `ORDER BY` |
| 66 | + |
| 67 | +Ordering requires wrapping the ordered column in the `eql_v1.order_by` function, like this: |
| 68 | + |
| 69 | +```sql |
| 70 | +SELECT * FROM users ORDER BY eql_v1.order_by(encrypted_created_at) DESC |
| 71 | +``` |
| 72 | + |
| 73 | +PostgreSQL uses operators when handling `ORDER BY` operations. The `eql_v1.order_by` function behaves in |
| 74 | + |
0 commit comments