On Mon, Jun 15, 2026 at 11:57 AM vignesh C <[email protected]> wrote:
>
> While reviewing operations on the pg_conflict schema, I noticed a few
> behaviors that I wasn't sure were intentional.
> 1. REINDEX is allowed on conflict log tables
> postgres=# REINDEX TABLE pg_conflict.pg_conflict_log_16404;
> REINDEX
>
> I was not sure whether allowing REINDEX on conflict log tables is
> intentional, given that these are system-managed tables.
>
I think this should be disallowed.
> 2. Views are disallowed, but functions are allowed
> Creating a view in the pg_conflict schema is rejected:
> postgres=# CREATE VIEW v1 AS
> SELECT * FROM pg_conflict.pg_conflict_log_16435;
> ERROR: permission denied to create "pg_conflict.v1"
> DETAIL: Conflict schema modifications are currently disallowed.
>
> However, creating a function in the same schema succeeds:
> CREATE FUNCTION pg_conflict.get_conflict_count()
> RETURNS bigint
> LANGUAGE sql
> AS $$
> SELECT count(*) FROM pg_conflict.pg_conflict_log_16404;
> $$;
> CREATE FUNCTION
>
This is okay because the function is doing SELECT which we allow on
these tables.
> I noticed similar behavior with the pg_toast schema as well, where
> function creation is allowed:
>
> CREATE FUNCTION pg_toast.get_toast_1213_count()
> RETURNS bigint
> LANGUAGE sql
> AS $$
> SELECT count(*) FROM pg_toast.pg_toast_1213;
> $$;
> CREATE FUNCTION
>
> I am not sure what the rationale is for permitting some object types
> while rejecting others.
>
> 3. Functions can be created, but triggers cannot:
> Although function creation succeeds, trigger creation on a conflict
> log table is rejected:
> CREATE TRIGGER conflict_audit
> AFTER INSERT
> ON pg_conflict.pg_conflict_log_16435
> FOR EACH ROW
> EXECUTE FUNCTION get_conflict_count();
> ERROR: permission denied: "pg_conflict_log_16435" is a conflict log table
> DETAIL: Conflict log tables are system-managed tables for logical
> replication conflicts.
>
> Again, I wasn't sure whether this distinction is intentional.
>
I have given the reason for functions above and this restriction is okay.
> 4. User-defined types and domains are allowed
> CREATE TYPE pg_conflict.conflict_status AS ENUM ('ACTIVE', 'INACTIVE');
> CREATE TYPE
>
> CREATE DOMAIN pg_conflict.positive_int
> AS integer
> CHECK (VALUE > 0);
> CREATE DOMAIN
>
> I was also surprised that creating types and domains is permitted in
> the pg_conflict schema.
>
> Overall, I am having some difficulty understanding the rules governing
> which operations are allowed and which are disallowed in the
> pg_conflict namespace. If these behaviors are intentional, would it
> make sense to document the supported and unsupported operations more
> clearly? That would help avoid confusion for users.
>
Ideally, we should allow only SELECT, DELETE, and TRUNCATE for
allowing users to view and maintain the CLT tables. We are also
planning to allow the LOCK command for the purpose of pg_dump.
--
With Regards,
Amit Kapila.