Skip site navigation (1) Skip section navigation (2)

the case for machine-readable error fields

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: the case for machine-readable error fields
Date: 2009-08-04 17:12:10
Message-ID: 20090804171210.GL6494@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Responses

pgsql-hackers by date

Next:From: Kevin FieldDate: 2009-08-04 17:13:10
Subject: Re: 8.4 win32 shared memory patch
Previous:From: Tom LaneDate: 2009-08-04 16:47:39
Subject: Re: bytea vs. pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group