Re: enhanced error fields

Peter Geoghegan escribió:
>
> I think that we're both going to be busy next week, since we're both
> attending pgconf.eu. For that reason, I would like to spend some time
> tomorrow to get something in shape, that I can mark "ready for
> committer". I'd like to get this patch committed during this
> commitfest. You are welcome to do this work instead. I want to avoid a
> redundant effort.
>
> Let me know if you think that that's a good idea.

I guess you didn't get around to it.

Here are my own notes about this patch.

* Why doesn't errconstraint() set the err table directly? Having to call errrel()
separately seems pointless. I propose errconstraint sets both things; when
the two tables differ, call errconstraint first and then errrel() to overwrite.

* Some constraints do not have an associated relation name; for example
constraints on domains. I think we should report the constraint name
there, if one exists (in domain_check_input, ExecEvalCoerceToDomain
it doesn't). How about errconstraint() does not take a relation, and
have a new errconstraintrel() that receives the relation to which the
constraint is attached. Alternatively, have errconstraint() accept a
NULL relation for the cases where there is none.

* The distinction between oldrel/newrel in certain callers seems
useless; for example if we're rewriting a table due to ALTER TABLE, both
the new and old rel have the same name. That could be cleaned up.

* Some errrel() calls are getting an index ... is this sane? I think we
should be reporting the table name, not the index name.

* There are some pointless whitespace changes in elog.h. I suggest
passing everything through pgindent.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services