Re: Proposal: Conflict log history table for Logical Replication

On Tue, Jun 16, 2026 at 10:30 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> 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.

IMHI, while we could allow view creation, it is unlikely users will
perform operations critical enough to require views or stored
procedures on the CLT. For the initial version, providing SELECT,
DELETE, and TRUNCATE permissions should be sufficient. We can
introduce support for views and user- or system-created indexes in
subsequent releases.

--
Regards,
Dilip Kumar
Google