Re: Remove redundant comment regarding RelationBuildRowSecurity in relcache.c

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

In response to

Browse pgsql-hackers by date

  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)