Skip to content

Apply SELECT policies if RETURNING has cols #19720

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Apply SELECT policies if RETURNING has cols #19720

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b4a1966
Apply `SELECT` policies if `RETURNING` has cols
rmloveland Jun 5, 2025
8af8a1f
Update with spilchen feedback (1)
rmloveland Jun 10, 2025
82d8fa7
Update with spilchen feedback (2)
rmloveland Jun 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 16 additions & 11 deletions src/current/v25.2/create-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,20 +53,25 @@ The `USING` and `WITH CHECK` expressions can reference table columns and use ses

The following table shows which policies are applied to which statement types, with additional considerations listed after the table.

| Command / clause pattern | `SELECT` policy - `USING` (row that already exists) | `INSERT` policy - `WITH CHECK` (row being added) | `UPDATE` policy - `USING` (row before the change) | `UPDATE` policy - `WITH CHECK` (row after the change) | `DELETE` policy - `USING` (row to be removed) |
|-------------------------------------|-----------------------------------------------------|--------------------------------------------------|---------------------------------------------------|-------------------------------------------------------|-----------------------------------------------|
| `SELECT` | ✓ | — | — | — | — |
| `SELECT ... FOR UPDATE / FOR SHARE` | ✓ | — | ✓ | — | — |
| `INSERT` | — | ✓ | — | — | — |
| `INSERT ... RETURNING` | ✓ | ✓ | — | — | — |
| `UPDATE` | ✓ | — | ✓ | ✓ | — |
| `DELETE` | ✓ | — | — | — | ✓ |
| `INSERT ... ON CONFLICT DO UPDATE` | ✓ | — | ✓ | ✓ | — |
| `UPSERT` | ✓ | — | ✓ | ✓ | — |
| Command / clause pattern | `SELECT` policy - `USING` (row that already exists) | `SELECT` policy - `USING` (row being added) | `INSERT` policy - `WITH CHECK` (row being added) | `UPDATE` policy - `USING` (row before the change) | `UPDATE` policy - `WITH CHECK` (row after the change) | `DELETE` policy - `USING` (row to be removed) |
|--------------------------------------|-----------------------------------------------------|---------------------------------------------|--------------------------------------------------|---------------------------------------------------|-------------------------------------------------------|-----------------------------------------------|
| `SELECT` | ✓ | — | — | — | — | — |
| `SELECT ... FOR UPDATE / FOR SHARE` | ✓ | — | — | ✓ | — | — |
| `INSERT` | — | ✓ | ✓ | — | — | — |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed that we don't apply SELECT policies on this INSERT (3rd column). It can only be applied in the INSERT ... RETURNING case, and only if the column is referenced in the RETURNING clause, which you have covered.

| `INSERT ... RETURNING` | — | ✓(a) | ✓ | — | — | — |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the ✓(a) cases, if the policy is violated the statement will fail. So, it's kind of like ✓(b) except that its conditionally applied if any columns are referenced in the SET, WHERE or RETURNING clause.

| `UPDATE` | ✓ | ✓(a) | — | ✓ | ✓ | — |
| `DELETE` | ✓ | — | — | — | — | ✓ |
| `INSERT ... ON CONFLICT DO UPDATE` | ✓(b) | ✓(b) | — | ✓ | ✓ | — |
| `UPSERT` | ✓(b) | ✓(b) | — | ✓ | ✓ | — |

- ✓: Always applied when fetching an existing row for `UPDATE` or `DELETE` (CockroachDB uses the `USING` policy to filter rows before modifying or deleting).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the ✓ in cells for SQL statements that aren't UPDATE or DELETE. Also, it's used in cells for the WITH CHECK expression. I wonder if this should just say something like 'Always applied', without going into detail about the SQL statements and expression type.

- (a): Applied on write statements (`INSERT ... RETURNING`, `UPDATE`, `DELETE`) only when the statement references row columns (e.g., in `WHERE`, `SET`, or `RETURNING`), since those references require reading the row.
- (b): A `USING` policy failure causes the statement to fail. Normally, `USING` filters out rows silently.

In other words, during writes, the `SELECT` policy is always applied to the existing row. For the new row being inserted or updated, it's only applied if that row is referenced in the `WHERE`, `SET`, or `RETURNING` clause, since those clauses require reading from it.

Additional considerations include:

- `SELECT` evaluation: CockroachDB always evaluates `SELECT` (`USING`) policies for `INSERT`, `UPDATE`, and `DELETE`, even when the statement doesn't reference table columns.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we include further details as to when the SELECT policies will be applied during an INSERT/UPDATE/DELETE? SELECT policies are always applied during the fetch of the existing row (for UPDATE or DELETE). If a column is referenced in the WHERE, SET or RETURNING clause, then SELECT policies will also get applied during the write.

I think the postgres docs handled this by adding superscript numbers to the above table as an additional addendum.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've taken a shot at addressing this feedback in 8af8a1f

tried to incorporate the info from your comment and add some superscripts and more explanation

PTAL!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During writes, the SELECT policy is always applied to the existing row. For the new row being inserted or updated, it's only applied if that row is referenced in the WHERE, SET, or RETURNING clause, since those clauses require reading from it.

It might be worth adding a column to the chart for this distinction.

The values for chart would be:

Command / SELECT policy - USING (row that already exists) / SELECT POLICY - USING (row being added)
SELECT / ✓ / -
SELECT … FOR UPDATE / ✓ / -
INSERT / - / ✓
INSERT … RETURNING / - / ✓(a)
UPDATE / ✓ / ✓(a)
DELETE / ✓ / -
INSERT … ON CONFLICT / ✓(b) / ✓(b)
UPSERT / ✓(b) / ✓(b)

For UPSERT and it's variants, we have slightly different behaviour. So, I added (b) which means:

  • (b) A USING policy failure causes the statement to fail. Normally, USING filters out rows silently.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for explaining this @spilchen! still wrapping my head around some of this stuff. I took a shot at incorporating your feedback in 82d8fa7, PTAL when you get a chance. I think it's faithful to your comment with just light edits, but pls let me know

- {% include {{ page.version.version }}/known-limitations/rls-values-on-conflict-do-nothing.md %} This is a [known limitation](#known-limitations).

## Examples
Expand Down
Loading