Re: Patch to implement pg_current_logfile() function

On Tue, 17 Jan 2017 23:00:43 +0100
Gilles Darold <gilles(dot)darold(at)dalibo(dot)com> wrote:

> Le 17/01/2017 à 19:58, Karl O. Pinc a écrit :
> > On Tue, 17 Jan 2017 19:06:22 +0100
> > Gilles Darold <gilles(dot)darold(at)dalibo(dot)com> wrote:
> >
> >> Le 17/01/2017 à 03:22, Michael Paquier a écrit :
> >>> On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc <kop(at)meme(dot)com>
> >>> wrote:
> >>>> On January 15, 2017 11:47:51 PM CST, Michael Paquier
> >>>> <michael(dot)paquier(at)gmail(dot)com> wrote:
> >
> >>>>> Also, I would rather see an ERROR returned to the user in case
> >>>>> of bad data in current_logfiles, I did not change that either as
> >>>>> that's the original intention of Gilles.
> >> I'm not against adding a warning or error message here even if it
> >> may never occurs, but we need a new error code as it seems to me
> >> that no actual error code can be used.
> > Seems to me the XX001 "data_corrupted" sub-category of
> > XX000 "internal_error" is appropriate.
>
> I don't think so, this file doesn't contain any data and we must not
> report such error in this case. Somethink like "bad/unknow file
> format" would be better.

Maybe. It's not user-supplied data that's corrupted but it is
PG generated data which is generated for and supplied to the user.
I just looked at all uses of XX001 and it is true that they all
involve corruption of user-supplied data.

If you don't want to use XX001 use XX000. It does not seem worth
making a new error code for just this one case.

Regards,

Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein