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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
