On Mon, 2005-02-07 at 21:25 -0500, Tom Lane wrote: > I haven't looked lately, but my recollection is that there are just a > few calls into the main backend from pl_comp.c. I'm not sure they are > all to backend/parser though; check /catalog, etc as well.
Attached is a patch that implements this. I could only find a few places that needed to switch into the temporary context; thankfully, doing that wasn't _too_ ugly, since it allows us to dispense with retail pfrees in the function as well. The patch also has mostly-finished support for better PL/PgSQL syntax checking (per the discussion on the subject from a few months ago). My original implementation did the syntax checking after parsing was complete; this version does the checking in gram.y itself, so it should hopefully be more resilient against syntax errors that confuse statement boundaries and the like. It would have been nice to check for errors in plpgsql_read_expression() itself (rather than adding checks in most of its call sites), but we sometimes use plpgsql_read_expression() to read malformed SQL (e.g. gram.y:1069) -- it might be possible to fix that. I need to add some more regression tests and clean up the error message we emit on a syntax error, but the rest of the work is done. -Neil
plpgsql_cleanup-23.patch.gz
Description: GNU Zip compressed data
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings