Re: Docs and tests for RLS policies applied by command type

On Mon, 27 Oct 2025 at 05:03, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> v2-0001 looks good to me.

Thanks. I've pushed that one.

> > A recent commit reminded me that COPY ... TO also applies RLS SELECT
> > policies (and so does TABLE, though I doubt many people use that), so
> > I think it's worth testing and documenting those too. Updated patches
> > attached.
>
> other Utility commands will also invoke the SELECT/UPDATE policy.
> The below several commands will invoke SELECT or UPDATE policy,
> if rls_test_src have SELECT or UPDATE policy on it.

I don't think it's worth documenting every single command that
includes a SELECT somewhere in it. Adding too much to the docs makes
them harder to read, not easier, and I think it's pretty clear that
these examples end up executing a SELECT, and so it should be clear
that they apply the RLS SELECT/UPDATE policies.

In fact, on reflection, I don't think it's worth mentioning TABLE here
either, since it's not really a separate command. It doesn't have its
own doc page, but instead is only mentioned on the SELECT doc page,
which says that it's equivalent to SELECT * FROM table, so it should
be clear that it applies SELECT policies.

So I think I'll stick to just mentioning COPY .. TO, since it might
not otherwise be obvious that it does apply RLS SELECT policies.

> While at it, I found out that
> table "Policies Applied by Command Type" was missing SELECT FOR NO KEY UPDATE
> and SELECT FOR KEY SHARE.

I don't think that's necessary. We could try to say something like
"SELECT ... FOR [NO KEY] UPDATE / [KEY] SHARE", but I think that would
make it harder to read, given the lack of space in that table. Several
other places in the documentation already use the text "FOR
UPDATE/SHARE" to include all 4 variants of SELECT row locking,
including the SELECT doc page itself, so I think it should be
sufficient here too.

> While at it create_policy.sgml, I am not sure the below sentence is
> not fully accurate.
> ""
> If an INSERT or UPDATE command attempts to add rows to the table that do not
> pass the ALL policy's WITH CHECK expression, the entire command will be aborted.
> ""
> The above sentence fails to mention the case when the WITH CHECK
> expression does not exist.

Hmm, the sentence immediately before that explains that the USING
expression will be used to check new rows, if there is no WITH CHECK
expression, but that's using UPDATE as an example, so I guess it's
worth being clear that the same applies to an INSERT.

Updated patch attached.

Regards,
Dean