Thread: plpgsql_check_function - plan for 9.4

plpgsql_check_function - plan for 9.4

From

Pavel Stehule

Date:

01 April 2013, 22:25:06

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