Hi Jian, I tried the v3 patch for “CREATE TABLE LIKE INCLUDING POLICIES” on PostgreSQL 19devel.
I built PostgreSQL from source and applied the patch. The documentation part had a small reject because of version differences, but the actual code changes applied without issues. I also ran make check, and all regression tests passed. During testing, I first confirmed the current behavior where CREATE TABLE ... LIKE ... INCLUDING ALL does not copy RLS policies. After applying the patch, CREATE TABLE t2 (LIKE t1 INCLUDING POLICIES) correctly copied the policies to the new table. I also checked that the copied policies appear with row security disabled, which seems reasonable since they only take effect if RLS is explicitly enabled on the new table. After enabling RLS, the copied policies were enforced correctly for a non-owner user. In addition, I tried a few other cases such as multiple policies and a policy with a subquery referencing another table. In those cases as well, the policies were copied and behaved as expected. Overall, the patch worked well in my testing. Thanks for working on this feature. Regards, Lakshmi On Wed, Mar 4, 2026 at 12:44 PM jian he <[email protected]> wrote: > On Sat, Feb 14, 2026 at 2:03 AM Tom Lane <[email protected]> wrote: > > > > jian he <[email protected]> writes: > > > +CREATE TABLE coll_t1(LIKE coll_t INCLUDING POLICIES); > > > > I want to take a step back and debate whether such a feature is > > a good idea at all. > > > > IMHO, It's generally a good thing to make the target table produced by > CREATE TABLE LIKE be very close to the source table. > > > What's bothering me in particular is that CREATE TABLE LIKE does > > not (and cannot be told to) copy the source's ownership or ACL > > permissions. Does it make sense to copy RLS policies while > > not copying those tightly-associated properties? I'm inclined to > > think not. > > > ok. I will first think about how doable it's to implement: > CREATE TABLE LIKE INCLUDING ACL. > > > I'm especially distressed that this would presumably cause > > INCLUDING ALL to copy policies too. I think the odds of that > > usually being the right thing would be small. > > > > > https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DESC-DISABLE-ENABLE-ROW-LEVEL-SECURITY > >>>>>QUOTE > Note that policies can exist for a table even if row-level security is > disabled. In this case, the policies will not be applied and the > policies will be ignored. > >>>>>QUOTE > > https://www.postgresql.org/docs/current/sql-createpolicy.html > >>>>>QUOTE > Note that row-level security must be enabled on the table (using ALTER > TABLE ... ENABLE ROW LEVEL SECURITY) in order for created policies to > be applied. > >>>>>QUOTE > > CREATE TABLE coll_t1(LIKE coll_t INCLUDING ALL); > source table's policy will copied, and will not applied. > > It copies source table objects, and you must manually execute another > command (ALTER TABLE ... ENABLE ROW LEVEL SECURITY) for it to take > effect. > When you are executing ALTER TABLE ... ENABLE ROW LEVEL SECURITY, you > obviously understand what you are doing. > > So this is safe? > > > > -- > jian > https://www.enterprisedb.com/ > > > > >
