Re: Can the backend return more than one error message per PQexec?

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.

(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. This is not a permanent workaround for the protocol
problems, though.)

> In any case, we could say that only a line beginning with a known
> keyword starts a new field.

That would probably require a protocol minor version bump anytime a
keyword is added. A maintenance pain keeping both sides in sync.

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 wrote:]
> > Okay, so PQerrorMessage will print the whole glob, whereas there would be
> > an accessor method that would filter out the fields.

I think there will a problem with programs that parse the error messages
in lack of a better idea. Also, newlines are non-printing sometimes (see
above), so this would produce a glob of garbage.

I think an additional API is necessary. If you want extra information you
need to ask for it. In fact, most of the additional information will be
intended to be processed by a program, the error message text is the only
thing humans need to see by default.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter