the case for machine-readable error fields

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема the case for machine-readable error fields
Дата
Msg-id 20090804171210.GL6494@alvh.no-ip.org
обсуждение исходный текст
Ответы Re: the case for machine-readable error fields  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: the case for machine-readable error fields  (Sam Mason <sam@samason.me.uk>)
Список 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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: bytea vs. pg_dump
Следующее
От: "Kevin Field"
Дата:
Сообщение: Re: 8.4 win32 shared memory patch