On Thu, Dec 21, 2023 at 5:05 PM Andres Freund <and...@anarazel.de> wrote: > > On 2023-12-21 16:08:48 +0530, shveta malik wrote: > > On Thu, Dec 21, 2023 at 3:10 PM Andres Freund <and...@anarazel.de> wrote: > > > > > > Extra columns aren't free from a usability perspective. IFF we do > > > something, I > > > think it should be a single column with a cause. > > > > Thanks for the feedback. But do you mean that we replace existing > > 'conflicting' column with 'cause' in both the function and view > > (pg_get_replication_slots() and pg_replication_slots)? Or do you mean > > that we expose 'cause' from pg_get_replication_slots() and use that to > > display 'conflicting' in pg_replication_slots view? > > 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. 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. > > > 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. -- With Regards, Amit Kapila.