Skip site navigation (1) Skip section navigation (2)

Proposal: integration plpgpsm into core PostgreSQL

From: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Proposal: integration plpgpsm into core PostgreSQL
Date: 2007-03-26 11:53:03
Message-ID: BAY114-F1345508D533CDD9E99CC23F96F0@phx.gbl (view raw or flat)
Thread:
Lists: pgsql-hackers
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/


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-03-26 13:18:31
Subject: Re: tsearch2 regression test failures
Previous:From: Magnus HaganderDate: 2007-03-26 11:16:31
Subject: Re: tsearch2 regression test failures

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group