Re: Proposal: Conflict log history table for Logical Replication

On Tue, Jun 16, 2026 at 10:21 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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:
> > >
> > > 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?
> >
>
> I think sticking to the minimum set of commands that are required for
> the user to monitor/maintain CLT should be a good goal for the first
> version. We can evaluate to allow other commands based on real user
> need and its impact on the functionality. So, it is okay to block even
> the view on CLT for now.
>

A view is essentially just a stored SELECT query, I think it should be
allowed in the first version itself. Rest (functions, indexes,
statistics etc) can be decided and implemented later based on user's
feedback.

thanks
Shveta