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

Tom Lane writes:

> This doesn't seem like a good argument not to add more information to
> the CONTEXT line for COPY errors. Sure, in theory the existing info
> should be sufficient, but what if the information is not coming in
> through psql? (For instance, maybe the COPY data is being generated
> on-the-fly by some other program.)

Then you look into the code of that other program. Or you look into the
server log, where you should log the statements you generate if you are
testing your code.

> Or what if the dump file is so large you can't easily edit it to
> determine which line number is in question?

The line number is already contained in the available information about
the error. If the file is too large to load into an editor, you could use

perl -npi -e '$. == 123456 and s/\r/\\r/;'

or something along those lines.

> There are plenty of scenarios where it's not all that convenient to
> triangulate on a problem from outside information.

Maybe, but the ones I've seen mentioned so far are not among them. I'm
not opposed to making errors more easy to identify, but considering that
someone else in this thread didn't even know about psql's option to print
line numbers of errors, I think some people haven't done their homework
yet.

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

--
Peter Eisentraut peter_e(at)gmx(dot)net