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
proposeerrconstraint 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
reportthe 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
constraintis 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
ALTERTABLE, 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
indexname. 

* 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