Thread: cleaning up in UDF's (user-defined functions)

cleaning up in UDF's (user-defined functions)

From
craig perras
Date:
I appended an excerpt from the docs... IIUC, if I make
a DSQL call from a UDF (written in C), and there's a
transaction abort caused by that command, then my
function is never called back. How do I cleanup any
resources the function allocated if this is the case?

I'm not even sure how I could NOTIFY clients, since
the transaction aborted.

thanks!
--craig

Note that if during the execution of a procedure the
transaction is aborted because of an error in a
command, then control will not be returned to your
procedure. Rather, all work will be rolled back and
the server will wait for the next command from the
client. A related restriction is the inability to
execute BEGIN, COMMIT, and ROLLBACK (transaction
control statements) inside a procedure. Both of these
restrictions will probably be changed in the future.


    
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


Re: cleaning up in UDF's (user-defined functions)

From
Tom Lane
Date:
craig perras <craigp98072@yahoo.com> writes:
> I appended an excerpt from the docs... IIUC, if I make
> a DSQL call from a UDF (written in C), and there's a
> transaction abort caused by that command, then my
> function is never called back. How do I cleanup any
> resources the function allocated if this is the case?

What resources?  Most stuff (like palloc'd memory) is taken care of
for you.  If you're maintaining your own private permanent data
structures then you may need to plug in a transaction-end hook
routine to clean those up.

pgsql-interfaces is hardly the place for discussing how to write
C-language server functions; if you want to discuss the fine points
I'd suggest pgsql-hackers.
        regards, tom lane