ENABLE ROW LEVEL SECURITY on partitioned tables is neither dumped nor diffed (policies are, so the gap is silent)

[thomas-huerlimann]

Summary

ENABLE ROW LEVEL SECURITY on a partitioned table (relkind p) is neither dumped nor diffed. Policies on the partitioned table ARE dumped correctly, which makes the gap easy to miss: a fresh database built from the dump ends up with all policies present but RLS not enabled on partitioned tables, so the policies are silently not enforced.

Regular tables (relkind r) are handled correctly.

Repro (pgschema 1.11.1, PostgreSQL 17)

CREATE TABLE events (
    id uuid NOT NULL,
    org_id uuid NOT NULL,
    created_at timestamptz NOT NULL,
    PRIMARY KEY (created_at, id)
) PARTITION BY RANGE (created_at);

ALTER TABLE events ENABLE ROW LEVEL SECURITY;

CREATE POLICY events_org_isolation ON events
    USING (org_id = NULLIF(current_setting('app.current_org_id', true), '')::uuid);

1. pgschema dump output contains CREATE POLICY events_org_isolation ... but no ALTER TABLE events ENABLE ROW LEVEL SECURITY; (for a regular table it is emitted).
2. Hand-adding ALTER TABLE events ENABLE ROW LEVEL SECURITY; to the desired-state file and running pgschema plan against a target where RLS is NOT enabled on events prints No changes detected - the statement is accepted by the temp-schema apply but excluded from the comparison model.

Expected

• dump emits ENABLE ROW LEVEL SECURITY for partitioned tables the same way it does for regular tables.
• plan detects an enable/disable difference on partitioned tables.

Why it matters

For multi-tenant schemas where partitioned tables (event logs, usage ledgers) carry the same org-isolation policies as regular tables, a bootstrap from the dump produces a database that looks correct (policies exist) but does not enforce them. This is the silent-failure direction.

Observed on both 1.10.0 and 1.11.1 (Docker images), server PostgreSQL 17.