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