Re: Function to get invalidation cause of a replication slot.
От | Amit Kapila |
---|---|
Тема | Re: Function to get invalidation cause of a replication slot. |
Дата | |
Msg-id | CAA4eK1Kr-GvSJPSnyJqQVHndAOW_Us4Qj1LhAhQ=Sy0DXHh+Fg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Function to get invalidation cause of a replication slot. ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>) |
Список | pgsql-hackers |
On Wed, Dec 20, 2023 at 4:10 PM Drouvot, Bertrand <bertranddrouvot.pg@gmail.com> wrote: > > On 12/20/23 9:50 AM, Amit Kapila wrote: > > On Wed, Dec 20, 2023 at 12:46 PM Drouvot, Bertrand > > <bertranddrouvot.pg@gmail.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.
В списке pgsql-hackers по дате отправления: