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://pgfoundry.org/projects/plpsm/
* 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 of 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 (not far) future, and with large user base, fixed parser, completed regress tests this task will be easier.

Pavel Stehule

Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to