pgsql: This patch changes makes some significant changes to how

Log Message:
-----------
This patch changes makes some significant changes to how compilation
and parsing work in PL/PgSQL:

- memory management is now done via palloc(). The compiled representation
of each function now has its own memory context. Therefore, the storage
consumed by a function can be reclaimed via MemoryContextDelete().

During compilation, the CurrentMemoryContext is the function's memory
context. This means that a palloc() is sufficient to allocate memory
that will have the same lifetime as the function itself. As a result,
code invoked during compilation should be careful to pfree() temporary
allocations to avoid leaking memory. Since a lot of the code in the
backend is not careful about releasing palloc'ed memory, that means
we should switch into a temporary memory context before invoking
backend functions. A temporary context appropriate for such allocations
is `compile_tmp_cxt'.

- The ability to use palloc() allows us to simply a lot of the code in
the parser. Rather than representing lists of elements via ad hoc
linked lists or arrays, we can use the List type. Rather than doing
malloc followed by memset(0), we can just use palloc0().

- We now check that the user has supplied the right number of parameters
to a RAISE statement. Supplying either too few or too many results in
an error (at runtime).

- PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we
do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this
means we need to be quite lax in what the PL/PgSQL grammar considers
a "SQL statement". This can lead to misleading behavior if there is a
syntax error in the function definition, since we assume a malformed
PL/PgSQL construct is a SQL statement. Furthermore, these errors were
only detected at runtime (when we tried to execute the alleged "SQL
statement" via SPI).

To rectify this, the patch changes the parser to invoke the main SQL
parser when it sees a string it believes to be a SQL expression. This
means that synctically-invalid SQL will be rejected during the
compilation of the PL/PgSQL function. This is only done when compiling
for "validation" purposes (i.e. at CREATE FUNCTION time), so it should
not impose a runtime overhead.

- Fixes for the various buffer overruns I've patched in stable branches
in the past few weeks. I've rewritten code where I thought it was
warranted (unlike the patches applied to older branches, which were
minimally invasive).

- Various other minor changes and cleanups.

- Updates to the regression tests.

Modified Files:
--------------
pgsql/src/pl/plpgsql/src:
gram.y (r1.65 -> r1.66)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/gram.y.diff?r1=1.65&r2=1.66)
pl_comp.c (r1.83 -> r1.84)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_comp.c.diff?r1=1.83&r2=1.84)
pl_exec.c (r1.129 -> r1.130)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c.diff?r1=1.129&r2=1.130)
pl_funcs.c (r1.38 -> r1.39)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_funcs.c.diff?r1=1.38&r2=1.39)
pl_handler.c (r1.23 -> r1.24)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_handler.c.diff?r1=1.23&r2=1.24)
plpgsql.h (r1.56 -> r1.57)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/plpgsql.h.diff?r1=1.56&r2=1.57)
scan.l (r1.38 -> r1.39)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/scan.l.diff?r1=1.38&r2=1.39)
pgsql/src/test/regress/expected:
plpgsql.out (r1.25 -> r1.26)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/plpgsql.out.diff?r1=1.25&r2=1.26)
pgsql/src/test/regress/sql:
plpgsql.sql (r1.20 -> r1.21)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/plpgsql.sql.diff?r1=1.20&r2=1.21)