Re: Function to get invalidation cause of a replication slot.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Function to get invalidation cause of a replication slot.
Date: 2023-12-20 10:48:20
Message-ID: CAA4eK1Kr-GvSJPSnyJqQVHndAOW_Us4Qj1LhAhQ=Sy0DXHh+Fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 20, 2023 at 4:10 PM Drouvot, Bertrand
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> On 12/20/23 9:50 AM, Amit Kapila wrote:
> > On Wed, Dec 20, 2023 at 12:46 PM Drouvot, Bertrand
> > <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> >>
> >
> >> 4 ===
> >>
> >> + * Returns ReplicationSlotInvalidationCause enum value for valid slot_name;
> >>
> >> I think it would be more user friendly to return a description instead of an enum value.
> >>
> > But it would be tricky to use at a place where we want to know the
> > enum value as in the case of the sync slots patch where we want to
> > copy the cause.
>
> Yeah right, what about displaying both then? (one field for the enum and one for
> the description). I feel it's not friendly to ask users to refer to the documentation
> (or the commit message) to get the meaning of the output.
>
> Another option could be to create a new view, say pg_slot_invalidation_causes, that would list
> them all (cause_id, cause_description) and then keep pg_get_slot_invalidation_cause() returning
> the cause_id only.
>

I am not sure if it is really valuable enough to have a separate view
but if others also feel that would be a good idea then we can do it. I
feel for the current purpose having a function as proposed in the
patch is good enough, we can always extend it or add a new view
dependening on if some users really care about it.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2023-12-20 11:14:32 Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
Previous Message vignesh C 2023-12-20 10:45:55 Re: Remove MSVC scripts from the tree