Re: Proposal: Conflict log history table for Logical Replication

On Tue, Jun 16, 2026 at 9:27 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Mon, 15 Jun 2026 at 14:20, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > > 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.
>
> Shouldn’t creating a view also be allowed for the same reason?
>
> The function is permitted because it only performs a SELECT on the
> conflict log table, and such read operations are allowed. A view
> likewise represents a stored query definition and does not modify the
> conflict schema or its underlying tables. Given that direct queries on
> the conflict log tables are already permitted, allowing users to
> define views over them is consistent with the same rationale applied
> to functions.

Whats is the behavior of toast table w.r.t the function vs view?

--
Regards,
Dilip Kumar
Google