Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
> Some fields may contain line breaks; for example, error messages
> definitely do now.
>>
>> Yes. I believe most of them are set up to indent the continuation
>> lines, so there wouldn't be much of a problem interpreting the format.
> This is not reliable.
It could be made reliable if we wanted it to be. AFAIR, in all the
places that currently emit error messages formatted like
ERROR: something
something else
the "something else" is not really part of the error message anyway.
It is explanatory material, a suggested workaround, or something like
that. IMHO that ought to be treated as a secondary field of the error
now that we're going to have secondary fields. Something like
ERROR: Unable to identify an operator '!' for types 'int4' and 'int4'
REMARK: You will have to retype this query using an explicit cast
> (Actually, it's not desirable either. Think about GUI or web applications
> or syslog: These formatting attempts are meaningless there. It'd be
> better to make error message mostly one-liners and worry about formatting
> in the front-ends.
I agree, but see above.
> Also, I imagine that with the nature of data that parse tree dumps and
> other such debugging info (vacuum verbose?) throw out, it's possible to
> have misinterpretations -- or even malicious attacks -- with these scheme.
I was not anticipating imposing any such structure on NOTICE messages.
> [I wrote:]
> Okay, so PQerrorMessage will print the whole glob, whereas there would be
> an accessor method that would filter out the fields.
I still think that is the right approach. The accessor methods would
become the preferred way over time, but we shouldn't hide available
information just because someone is using an old client.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
