Re: MERGE/SPLIT PARTITIONS issues/questions

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].

Links.
1. https://www.postgresql.org/message-id/CAN4CZFMNhEF85h7h1su30h9E4cExGKpSSViZ2EqggNqAX%2BXtng%40mail.gmail.com

------
Regards,
Alexander Korotkov
Supabase