plpgsql_check_function - plan for 9.4

Hello all

I would to draw a plan for 9.4. This patch was moved second times to next
release and now is time do decision about direction, how to implement this
functionality be acceptable (or leave it).

RECAPITULATION

What this patch does:
* it try to prepare plans for all expressions
* it check some statements, where compilation checking is not too deep (due
possible slowness)

Why this patch can be useful:
* it can find a lot of bugs without executions and ensure iteration over
all execution paths
* in some cases, only this method can identify bugs
* it can identify a performance issues - IO casting

Where this patch is armless:
* it doesn't work well (on 100%) with temporary tables and dynamic SQL

Why we don't do deep check in compilation time:
* speed - we don't would to prepare plans for newer evaluated expressions
* dependency - now compilation is dependency less, so we don't would to
prepare plans in compilation time

Why we don't do deep check in run time:
* code readability - isn't possible to modify runtime executor to touch all
possible execution paths
* speed - any new code in executor means significant slowdown in CPU
expensive functions - where critical path is over SPI routines and over
simple expression evaluation.

What is easy:
* iteration over abstract syntax tree and prepare plans

What is complicated:
* identification real types for variables declared as RECORD

CREATE FUNCTION f1(a int, OUT b int, OUT c int) ..

DECLARE r RECORD;
BEGIN
r := f1(10);
RAISE NOTICE '>>%', r.c;
RAISE NOTICE '>>%', r.x; --<< BUG

* record type should be unnested sometimes, sometimes not
-- this is different, then in previous example
BEGIN
FOR r IN SELECT * FROM f1(10)
LOOP
...

Objections:
Current implementation copies a compiler structure and uses some runtime
routines. It is about 45KB new code.

My plan:
* divide a current compiler to parser and compiler
* compiler is controlled by parsing AST trees and there are correct order
of processing.
* modified compiler is good place for placing deep check routines. We can
move dump routines there too.

It means significant plpgsql refactoring - and if this tassk should be done
in 9.4, then it should be committed in some early commitfest. So I should
to start work.

It is acceptable?

Objections, notes, ideas?

Regards

Pavel