Bruce Momjian <bruce@xxxxxxxxxx> writes: > This this a bug or TODO item? TODO, I think. I wouldn't want to risk pushing a change in this into back branches. regards, tom lane >> I'm not sure why it's like this. Some digging in the CVS history shows >> that indeed the code used to be in the other order, and I switched it >> (and added the second comment block) in this old commit: >> >> http://archives.postgresql.org/pgsql-committers/2000-08/msg00218.php >> >> I suppose that the SQL-function support at the time required that its >> calling memory context be persistent until it returned ExprEndResult, >> but I sure don't recall any details. It's entirely possible that that >> requirement no longer exists, or could easily be eliminated given all >> the other changes that have happened since then. nodeFunctionscan.c >> seems to reset the current context for each call of a SRF, so I'd think >> that anything that can't cope with that should have been flushed out >> by now. >> >> If you feel like poking at this, I *strongly* recommend doing your >> testing in an --enable-cassert build. You'll have no idea whether you >> freed stuff too early if you don't have CLOBBER_FREED_MEMORY enabled. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance
