the case for machine-readable error fields

Hi,

I think the case for machine-readable error fields is well made and
doesn't need any further push.

So, what do we need to make it happen? Here's my proposal.

First we need several new error message fields: table name, function
name, constraint name, and so on. One possible way to go about this
would be to give each new field its own start letter (see
http://www.postgresql.org/docs/8.4/static/protocol-error-fields.html);
say "T" for table, "f" for function (F is taken), "c" for constraint (C
is taken), and so on. Another possibility would be to use a single
letter, say N, and add a subtype to it; so table name would be "NT"
followed by the table name, NF for functions, etc.

The documentation on the FE/BE protocol already says that frontends
should ignore unrecognized type fields, so I don't think we need to bump
the protocol version for this.

The other part is getting the information in ErrorData. AFAICS this is
just a matter of adding a few setter functions; say errtable(),
errfunction(), etc. Furthermore, we can just add those to existing
errcontext callbacks, which would be pretty simple.

Thoughts?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.