Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 12, 2012 at 2:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not thrilled with the "line %d:" prefixes. That seems to me to
>> violate the letter and spirit of the guideline about making errdetail
>> messages be complete sentences. Furthermore, the line number is not
>> the most important part of the detail message, if indeed it has any
>> usefulness at all which is debatable. (It's certainly not going to
>> be tremendously useful when the error report doesn't show any of the
>> specific input string being complained of.)
> I am amenable to rephrasing the errdetail to put the line number
> elsewhere in the string, but I am strongly opposed to getting rid of
> it. JSON blobs can easily run to dozens or hundreds of lines, and you
> will want to know the line number.
Agreed, the input strings could be quite large, but in that case we
definitely don't want to be including the whole input in the primary
error message (which is supposed to be short). I doubt it'd even be
a good idea to try to put it into errdetail; thus I'm thinking about
providing one line only.
> Knowing the contents of the line
> will in many cases be LESS useful, because the line might contain,
> say, a single closing bracket.
True, but I don't think the line number alone is adequate. There are
too many situations where it's not entirely clear what value is being
complained of. (Considering only syntax errors thrown from literal
constants in SQL commands is quite misleading about the requirements
here.) So I think we need to include at least some of the input in
the error.
>> I notice that there's an unfinished attempt to maintain a line_start
>> pointer; if that were carried through, we could imagine printing the
>> current line up to the point of an error, which might provide a
>> reasonable balance between verbosity and insufficient context.
>> ...
>> or perhaps better let it run to the end of the line:
> I'm not sure I find that an improvement, but I'm open to what other
> people think.
Anybody here besides the crickets?
regards, tom lane
