Re: MERGE/SPLIT PARTITIONS issues/questions

On Fri, Aug 14, 2026 at 6:49 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Fri, Aug 14, 2026 at 5:51 PM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> >
> > On Fri, Aug 14, 2026 at 10:08 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > >
> > > > On 12 Aug 2026, at 22:48, Melanie Plageman <melanieplageman(at)gmail(dot)com> 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