Proposal PL/pgPSM
=================

I propose integrate a PSM language to core. This language is defined as part of ANSI SQL - SQL/PSM. This language 
is used in some well known databases like DB2, Terradata and some other less known RDBMS like MonetDB. A proposed
implementation is based on same architecture like current PL/pgSQL interpret - interpretation of AST with integration
of SQL parser and expression executor. Reasons why use same architecture are: reuse some parts of interpret and well 
expirience with current interpret.

One year ago I wrote a PSM compiler to pcode and pcode interpret - PSM0. This project showed so using pcode doesn't
carry any speedup over AST interpret - bottleneck was a expression execution - and PostgreSQL executor is part that
we would not substitute, so we can use simpler and well known AST interpret

Language is specified by standard - so I'll describe main differences against PL/pgSQL:

* Exception handlers are similar to couroutines (continue handlers).

* Warnings can be handled like exception - handling warnings is important and well known pattern

BEGIN
  DECLARE success boolean DEFAULT true;
  DECLARE _x varchar;
  DECLARE c CURSOR FOR SELECT x FROM tab;
  DECLARE CONTINUE HANDLER FOR NOT FOUND SET success = false;
  OPEN c;
  FETCH c INTO _x;
  WHILE success DO
    -- process _x
    FETCH c INTO _x;
  END WHILE;
  CLOSE c;
END;

* Declaration of variables should be based on SQL query result - and because we would to execute and check queries
  only in runtime, then we have to use little bit different rules for variables - variables should not be declared
  before they are used - it is possible, because there are different syntax for assign statement. Automatic variables
  should be read only.

BEGIN
  DECLARE s text;
  FOR SELECT curse FROM courses
  DO
    SET s = COALESCE(s || ',' curse, course);
  END FOR;

Other differences are minor.

Request:

* reusing important parts of plpgsql executor - simple expressions, using variables, assign results to variables

* support check function statement

* be near to standardt as is possible

* implement well known patterns that are not in standard, but that has impact on speed or useability
  and are used in well known implementations (SQLCODE variable, multi assign).

-- little bit more effective iteration (well known pattern)

BEGIN
  OPEN c;
  FETCH c INTO _x;
  WHILE SQLCODE = 0 DO
    -- process _x;
    FETCH c INTO _x;
  END WHILE;
  CLOSE c;
END;

* check strictly expression syntax
  don't allow plpgsql's " var := SELECT 10; var := a FROM tab " and similar, only 
  "set var = 10; or set var = (SELECT 10); or set var = (SELECT a FROM tab) should be allowed

LIMITS:

* PostgreSQL doesn't support procedures - statement CALL will not be supported (I would to see CALL statement
  as PostgreSQL statement, not only PSM emulation)

* I don't plan to implement PSM into SQL parser in first step. Reason - this feature needs introduction
  a DELIMITERs (like MySQL or DB2). This concept is not adapted in PostgreSQL - and my opinion and expirience
  - PostgreSQL design is more user friendly for work from command line tools. This can be enhanced in future,
  if we find a was how to extend bison parser. Using $$ limiters for function body doesn't block some future
  enhancing.


