From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | "Khan, Tanzeel" <tzlkhan(at)amazon(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove redundant comment regarding RelationBuildRowSecurity in relcache.c |
Date: | 2025-07-08 17:43:58 |
Message-ID: | CAEZATCWme5TumkTgtgaLixaj-3fmw4ZbRWV_FjF9bwpYOh8snA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 28 Apr 2025 at 16:02, Khan, Tanzeel <tzlkhan(at)amazon(dot)com> wrote:
>
> A comment in relcache.c mentions that RelationBuildRowSecurity
> adds a default-deny policy when no policy exists on table. This
> does not seem to be the case. The default deny policy is added
> later on, inside get_row_security_policies(). Also it mentions that
> there can never be zero policies for a relation which is true
> but here it kind of hints that rd_rsdesc->policies can never be
> null.
>
> Added a patch to remove both of these comments.
Hmm, well I agree that the comment is wrong, but I don't think that
simply deleting it is the answer.
I think that the point the comment is trying to make is that it's
perfectly valid for there to be no policies while relrowsecurity is
true, which is why the code block for policies needs to be different
from the preceding code blocks for rules and triggers.
So perhaps it should say something like this:
/*
* Re-load the row security policies if the relation has them, since
* they are not preserved in the cache. Note that relrowsecurity may
* be true even when there are no policies defined in pg_policy, in
* which case RelationBuildRowSecurity will create a RowSecurityDesc
* with an empty policy list, and rd_rsdesc will always be non-NULL.
* When the table is queried, if there are no policies granting access
* to rows in the table, a single always-false, default-deny policy
* will be applied instead, see get_row_security_policies.
*/
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-07-08 18:07:55 | Re: What is a typical precision of gettimeofday()? |
Previous Message | Burd, Greg | 2025-07-08 16:58:26 | Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem) |