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 <and...@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
