I have a C function (a trigger function) which uses the PG_TRY() construct to handle certain ERROR conditions. One example is where invoked as INSTEAD OF INSERT into a view. It PG_TRYs INSERT into the real base table, but this table may not yet exist (it is a partitioned child of an inheritance parent). If the error is ERRCODE_UNDEFINED_TABLE, then the CATCH issues FlushErrorState() and returns to caller who CREATes the table and re-issues the insert. All works perfectly (on every release of 9.x).
But in a different part of the same trigger function, there is a PG_TRY , PG_CATCH of a CREATE INDEX, which sometimes hits error "relation already exists" (i.e. index with same name indexing a different table). The CATCH issues FlushErrorState() and returns to caller who ignores the error. All works but not perfectly -- at COMMIT, resource_owner issues relcache reference leak messages about relation scans not closed and also about snapshot still active. I guess that the CREATE has switched resource_owner and pushed a snapshot, but I did not debug in detail. Those are just examples, but my question is whether use of this construct is legal in a C function (always? sometimes e,g only for DML but not DDL? never?), and if not, then how can one legally catch ERRORs like this in a C function? (Yes I realise I could write selects of pg_class to avoid these two particular cases rather than the try-and-fail approach but I would like to understand the general rules where it may be much harder to try avoidance) Cheers, John -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
