On Fri, Aug 14, 2026 at 6:49 PM Alexander Korotkov <[email protected]> wrote: > On Fri, Aug 14, 2026 at 5:51 PM Melanie Plageman > <[email protected]> wrote: > > > > On Fri, Aug 14, 2026 at 10:08 AM Daniel Gustafsson <[email protected]> wrote: > > > > > > > On 12 Aug 2026, at 22:48, Melanie Plageman <[email protected]> > > > > wrote: > > > > > > > The user needs to add RLS to the new leaf partitions if they want the > > > > same level of security, but I'm not sure that's intuitive. > > > > > > It's not, and it quite easily will leave the data without the intended > > > protection during a window. > > > > > > > Also, for merging partitions, if you merge two partitions that have > > > > the same RLS, after merging, the new merged partition doesn't have > > > > that RLS policy -- that seems confusing too > > > > > > I would rank this as even more unintuitive than the previous case, as a > > > user I > > > would expect the new partition to have the shared policy. > > > > > > Could we make this safe by restricting to the cases where partitions > > > match the > > > parent and we can make them not drop characteristics? If we want to > > > expand > > > which differences can be handled in a safe manner in 20 then we can > > > revisit, > > > rather than being very lax now and try to restrict later. > > > > Yes, I don't think it makes sense to silently drop the properties in > > 19 and then start automatically propagating them in 20. That seems > > like it will be really confusing for users that have scripts to, for > > example, recreate ACLs for the merged or split partition(s) when using > > 19. > > I agree that this kind of changing behavior is not acceptable. My > proposal is to reject partitions with row-level security/policies for > 19. Then we could add automatic copy of row-level security/policies > for 20. If changing one behavior to another incompatible behavior is > not acceptable, but changing from ERRCODE_FEATURE_NOT_SUPPORTED to new > behavior seems acceptable (new releases support more features). Or > alternatively we could add copying of row-level security/policies as > an option in SQL statement for 20. > > SPLIT/MERGE partition(s) seemed like not so complex feature, but many > aspects like this arise. It would be nice if we could come with some > restricted version for 19, and expand it for 20 and later releases > (rather than re-trying large patchset for 20). > > Attached 0004 implements check that source partition doesn't have > ow-level security/policies. > > 0003 also have integrated edits proposed by Zsolt [1].
Any objections to pushing these 4 fixes? ------ Regards, Alexander Korotkov Supabase
