Hi,
On Thu, Dec 21, 2023 at 07:55:51PM +0530, Amit Kapila wrote:
> On Thu, Dec 21, 2023 at 5:05 PM Andres Freund <andres@anarazel.de> wrote:
> > I'm not entirely sure I understand the difference - just whether we add one
> > new column or replace the existing 'conflicting' column? I can see arguments
> > for either.
> >
>
> Agreed. I think the argument against replacing the existing
> 'conflicting' column is that there is a chance that it is being used
> by some monitoring script which I guess shouldn't be a big deal to
> change. So, if we don't see that as a problem, I would prefer to have
> a single column with conflict reason where one of its values indicates
> there is no conflict.
+1
> A conflicting column where NULL indicates no conflict, and other
> > values indicate the reason for the conflict, doesn't seem too bad.
> >
>
> This is fine too.
+1
> >
> > > And if we plan to return/display cause from either function or view,
> > > then shall it be enum 'ReplicationSlotInvalidationCause' or
> > > description/text corresponding to enum?
> >
> > We clearly can't just expose the numerical value for a C enum. So it has to be
> > converted to something SQL representable.
> >
>
> We can return int2 value from the function pg_get_replication_slots()
> and then use that to display a string in the view
> pg_replication_slots.
Yeah, and in the sync slot related work we could use pg_get_replication_slots()
then to get the enum.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
