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