Re: [HACKERS] no error context for index updates?

[Tom Lane]

Peter Eisentraut  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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] no error context for index updates?

[Peter Eisentraut]

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 
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?

CREATE OR REPLACE LANGUAGE plpythonu;

CREATE OR REPLACE FUNCTION test1(x int) RETURNS int
IMMUTABLE STRICT
LANGUAGE plpythonu
AS $$
if x < 0:
plpy.error("boom")
return x
$$;

DROP TABLE IF EXISTS test;
CREATE TABLE test (a int, b text);

CREATE INDEX ON test ((test1(a)));

CREATE OR REPLACE FUNCTION test2(a int, b text) RETURNS int
LANGUAGE plpythonu
AS $$
plan = plpy.prepare('INSERT INTO test (a, b) VALUES ($1, $2)', ['int', 'text'])
rv = plpy.execute(plan, [a, b])
return rv.nrows()
$$;

SELECT test2(1, 'one');
SELECT test2(-1, 'neg one');

SELECT * FROM test;
CREATE OR REPLACE LANGUAGE plperl;

CREATE OR REPLACE FUNCTION test1(x int) RETURNS int
IMMUTABLE STRICT
LANGUAGE plperl
AS $$
elog(ERROR, "boom") if $_[0] < 0;
return $x;
$$;

DROP TABLE IF EXISTS test;
CREATE TABLE test (a int, b text);

CREATE INDEX ON test ((test1(a)));

CREATE OR REPLACE FUNCTION test2(a int, b text) RETURNS int
LANGUAGE plperl
AS $$
$plan = spi_prepare('INSERT INTO test (a, b) VALUES ($1, $2)', 'int', 'text');
$rv = spi_exec_prepared($plan, $_[0], $_[1]);
return $rv->{processed};
$$;

SELECT test2(1, 'one');
SELECT test2(-1, 'neg one');

SELECT * FROM test;

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers