pgsql: This patch changes makes some significant changes to how - Mailing list pgsql-committers

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)