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://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.
Regards
Pavel Stehule
_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
