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.


Attachment: 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

Reply via email to