[HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function - Mailing list pgsql-hackers

From John Lumby
Subject [HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function
Date
Msg-id DM5PR22MB1676C2FF997BF55615B1F063A3460@DM5PR22MB1676.namprd22.prod.outlook.com
Whole thread Raw
Responses Re: [HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function
Re: [HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: [HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC callsvery much
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] Block level parallel vacuum WIP