Re: WIP: pl/pgsql cleanup - Mailing list pgsql-patches

From Neil Conway
Subject Re: WIP: pl/pgsql cleanup
Date
Msg-id 1107846508.1286.69.camel@localhost.localdomain
Whole thread Raw
In response to Re: WIP: pl/pgsql cleanup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: pl/pgsql cleanup
Re: WIP: pl/pgsql cleanup
List pgsql-patches
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


Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: pl/pgsql cleanup
Next
From: Tom Lane
Date:
Subject: Re: WIP: pl/pgsql cleanup