Re: Another issue with invalid XML values
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Florian Pflug <fgp@phlo.org>, Noah Misch <noah@leadboat.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-07-20T14:08:32Z
Lists: pgsql-hackers
I wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> I was thinking that maybe it's time for this module to hook onto the >> cleanup stuff for the xact error case; or at least have a check that it >> has been properly cleaned up elesewhere. Maybe this can be made to work >> reentrantly if there's a global var holding the current context, and it >> contains a link to the next one up the stack. At least, my impression >> is that the PG_TRY blocks are already messy. > Yeah, that's another way we could go. But I'm not sure how well it > would interact with potential third-party modules setting up their own > libxml error handlers. Anybody have a thought about that? I thought a bit more about this, and realized that there's a big obstacle to getting rid of the PG_TRY blocks this way: most of them are responsible for telling libxml to free some data structures, not just restoring the error handler state. We can't drop that aspect without introducing session-lifespan memory leaks. In principle we could expand the responsibilities of a transaction-cleanup hook to include freeing data structures as well as restoring error handlers, but the idea seems a lot messier and hence less attractive than it did before. I was ready to get rid of the PG_TRY blocks until I came across this problem, but now I think I'll stick with them. regards, tom lane