Nathan Bossart writes:
> Perhaps another variation
> on this idea is to create a query walker that just looks for hasRowSecurity
> flags throughout the tree (and to use that to mark the plan cache entry
> appropriately).
That seems like a pretty plausible compromise position. So we'd
redefine Qu
On Mon, Feb 17, 2025 at 01:08:29PM -0500, Tom Lane wrote:
> I think you're being too impatient. It's still an interesting
> topic, it just needs more thought to get to something committable.
Maybe I am. Thanks for chiming in.
> I find this has-row-security marking problem to be comparable
> to
Nathan Bossart writes:
> Given there doesn't seem to be a huge amount of interest in this, I plan to
> mark it as Withdrawn soon.
I think you're being too impatient. It's still an interesting
topic, it just needs more thought to get to something committable.
I find this has-row-security marking
Given there doesn't seem to be a huge amount of interest in this, I plan to
mark it as Withdrawn soon.
--
nathan
On Fri, Nov 29, 2024 at 10:01:41AM +, Dean Rasheed wrote:
> On Thu, 21 Nov 2024 at 18:00, Nathan Bossart wrote:
>> The attached patch accomplishes this by establishing a global queue of
>> row-security "nest levels" that the aforementioned higher-level callers can
>> use.
>
> I'm not convince
On Thu, 21 Nov 2024 at 18:00, Nathan Bossart wrote:
>
> In light of CVE-2024-10976, which was fixed by commit cd7ab57, I'd like to
> propose a bigger change to this area of the code that aims to future-proof
> it a bit. Instead of requiring hackers to carefully cart around whether a
> query refer
