Thread: no error context for index updates?

Attached is a test case reduced from a real application.  There is a
table with an index on a function written in PL/Python.  There is a
second PL/Python function that executes an INSERT into the table,
causing an index update.  If the function used by the index fails, we
get an error message with context information, e.g.,

ERROR:  spiexceptions.InternalError: plpy.Error: boom
CONTEXT:  Traceback (most recent call last):
  PL/Python function "test2", line 3, in <module>
    rv = plpy.execute(plan, [a, b])
PL/Python function "test2"

I had been debugging the heck out of this function trying to figure out
where that particular exception is coming from, but it wasn't happening
on that function at all.

What I'd like to see if additional context like this:

CONTEXT: index updates of table "test"
CONTEXT: ....
PL/Python function "test1"

The second test case I'm attaching shows that the same thing happens
with PL/Perl, so it's not a problem of a particular PL.

Any ideas whether we could make this happen?

Peter Eisentraut <peter_e@gmx.net> writes:
> Any ideas whether we could make this happen?

Presumably you could do it by setting up an error context stack entry
within FormIndexDatum.  I'd want to be convinced that there was no
performance hit, but if you were to do it only in the expression-column
code path that would probably put it into the noise.  (So you could
actually mention the particular index column name, too, if you had a
mind to do that.)

[ pokes around a bit... ]  The major issue appears to be that
FormIndexDatum doesn't actually receive anything that tells it the index
name.  I'm not sure why we don't have a Relation pointer for the index
in there, but it looks like most of the work would be to verify that
that's safe --- are there any code paths where the index rel wouldn't
stay open for the lifetime of the IndexInfo node?  Or maybe, since
IndexInfo *is* a node and Relation isn't, it'd be better to just make
callers pass the index Relation separately.
        regards, tom lane