Neil Padgett <npadgett@redhat.com> writes:
> I think it seems that we all have a general idea of where we want to go
> with this. How about the following as a plan to get this ready for 7.2:
> 1. Leave elog() alone.
> 2. For syntax error reporting, and syntax error reporting alone, output
> the error message in the new, multi-line format from the backend.
> 3. Add functionality to psql for parsing the multi-line format error
> messages. (Probably this will form a reusable function library that
> other utilities can use.)
> 4. Modify psql to use this new functionality, but only for processing
> parse errors -- all other messages will be handled as is.
That seems like a good plan --- forward progress, and doable within the
7.2 time frame.
I think the thing we need to nail down next is the changes in the wire
protocol --- specifically, how the "multi line format" of error messages
will be defined. We don't necessarily need to define all the field
keywords yet, but we do need to have a clear idea of the format rules
and the parsing algorithm that clients will use. This might be trickier
than it seems at first glance, because we need both backwards and
forwards compatibility if we are to avoid a protocol version bump: not
only must old clients accept the new syntax (which is a no-op), but
new clients should behave reasonably well when fed messages from an old
backend (which might not adhere perfectly to the new syntax definition).
I'd suggest drawing up a straw-man definition and posting it on
pghackers and/or pginterfaces for comment.
Another thing to think about (orthogonally to the wire protocol) is
where on the client side to do the parsing. IMHO it'd be a good idea to
put as much of it as we can into libpq, where it'll be available
automatically to non-psql applications. Again, though, compatibility
is an issue.
regards, tom lane
