Re: Proposal: Conflict log history table for Logical Replication

On Tue, Jun 16, 2026 at 9:56 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 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?
>

Please see [1] for details.

[1]: https://www.postgresql.org/message-id/CAJpy0uDoa0CYWkxj52h%3DRM53acfsqjRihCfKrm8W%3DvRvHg01UA%40mail.gmail.com

thanks
Shveta