Zobrazení zdroje stránky SQL/Proposal Integration plpgpsm into core

Hello,

I propose integration plpgpsm into core PostgreSQL. 

plpgpsm is SQL/PSM language implementation for PostgreSQL based on pl/pgsql runtime. Currently this modified runtime exists for PostgreSQL 8.1, 8.2 and CVS HEAD. 

Some information:
* http://www.pgsql.cz/index.php/SQL/PSM
* http://www.pgsql.cz/index.php/SQL/PSM_Manual  Sun's people translate it to en.
* http://www.pgsql.cz/index.php/P%c5%99%c3%adru%c4%8dka_SQL/PSM  original documentation in czech

As far as I know, only one topic isn't well implemented - diagnostics fields, because PostgreSQL is very far to std. in this point. Over standard multi assignement is compatible with DB2 and MySQL, and SQLSTATE variable behave compatible with DB2. Statement PRINT is nonstandard too, but usefull if we have not debugger.

known problems:
* only few people know this language, minimum doc is available
* it shares all problems with plpgsql - not well structured code and some strange constructs in code
* code is duplicit for 50% (maybe more) with plpgsql

what can be better solved:
* I belive parser can be integrated into main parser (it's part of standard)
* with hypoteticle PL runtime API it can share code with plpgsql

whay I didn't it:
* I was afraid to do big changes in plpgsql runtime together with development of less or more experimental (in this moment) runtime (language). And this year was rich for changes in plpgsql runtime. Current implementation has zero impact on plpgsql runtime or core files. .. I sent scrollable cursor support and table expression patches which aren't directly related to plpgpsm. 

why add it to core?
* without additing into core plpgpsm will not have user base. It means nobody will check it, nobody will use it, nobody will correct regress tests and documentation.
* implementation of sql/psm is more complete than in MySQL and I sucesfully tested portability of MySQL stored procedures to plpgpsm.

next future steps?
* real integration into core (parser, executor) .. it can carry annonymous SQL/PSM statements, true session variables, posibility of diagnostic colission variables and attributes and more. It means strong reduction of plpgpsm runtime size.
* steps to bigger conformance with ANSI philosophy (three levels of exceptions which depend on SQLSTATE, diagnostics fields, possibility of handling any warnings, ...)


I belive plpgpsm is comparable with plpgsql and has more modern look and respect of standard, so it should be part of the core. I belive somebody will/should redesign plpgpsm and plpgsql in the future, and with large user base, fixed parser, completed regress tests this task will be easier.