Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Minimalism isn't really a virtue in error reports anyway.
>> I'm thinking maybe:
>> CONTEXT: COPY tablename, line 41: "data ..."
>> would serve the purpose nicely.

> The only thing that would really help in the general case is the number of
> the character where the error occurs. If you print the actual data you
> lose if the data is repeated within the, er, data and/or if the section of
> the data that you print contains crazy characters that mess up the
> display.

A messed-up display would be useful information in itself; and it's not
like we have no precedent for repeating the erroneous data in error
messages. Consider pg_atoi:

regression=# create table foo (f1 int);
CREATE TABLE
regression=# copy foo from stdin;
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> z44
>> \.
ERROR: invalid input syntax for integer: "z44"
CONTEXT: COPY FROM, line 1
regression=#

I was chewing this over with Bruce on the phone just now, and we refined
the idea a little. Some errors (primarily those detected inside the
datatype input procedures) can be clearly traced to a specific column,
whereas others (such as too many fields on an input line) really can't
be nailed down more tightly than a line. So we were thinking about two
different flavors of context info:

CONTEXT: COPY tablename, line n, field colname: "column data"

versus

CONTEXT: COPY tablename, line n: "line data"

where in each case the data display would be truncated at 100 characters
or so (and would have to be omitted in the COPY BINARY case anyway).

If you're really concerned about funny characters messing up the report,
we could imagine replacing them by backslash sequences or some such, but
I suspect that would create more confusion than it would solve.

regards, tom lane