On Tue, 17 Jan 2017 23:00:43 +0100
Gilles Darold <gilles.dar...@dalibo.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.dar...@dalibo.com> wrote:
> >> Le 17/01/2017 à 03:22, Michael Paquier a écrit :
> >>> On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc <k...@meme.com>
> >>> wrote:
> >>>> On January 15, 2017 11:47:51 PM CST, Michael Paquier
> >>>> <michael.paqu...@gmail.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.
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: