[Technik] Functions, Triggers und (Procedural) Languages in PostgreSQL, Was: Re: postgresql-contrib-8.1

[Christof Donat]

Hi,

> Wir haben folgende Möglichkeiten:
>
> a) Wir lassen keine externen Sprachen zu und beschränken damit Stored
> Procedures auf SQL und das interne PL/PGSQL. (Damit wäre auch der
> Einsatz von tsearch2 nicht möglich.)

Was auch bedeutet, dass man MediaWiki nur mit MySQL betreiben kann, weil 
MediaWiki das für die PostgreSQL Unterstützung braucht. Mit PostgreSQL 8.3 
gehört meines Wissens tsearch2 bereits zum Standardlieferumfang.

Ich weiß jetzt nicht, was genau nötig ist, damit man PostGIS betreiben kann. 
Wenn ich mich richtig erinnere, beinhaltet das auch ein paar PL/C Sachen.

> c) Wir lassen keine externen Sprachen zu und beschränken damit Stored
> Procedures auf SQL und das interne PL/PGSQL. Zusätzlich stellen wir
> ausgewählte, als sicher bekannte Funktionen zur allgemeinen Verwendung
> zur Verfügung. Darüberhinaus definieren wir diverse sichere Sprachen als
> trusted languages, damit User eigene Funktionen darin definieren können.

d) Wie Punkt b), nur dass die sicher bekannten Funktionen als 
Installationsskripte zur Verfügung gestellt werden. Man ruft also in der 
shell z.B. "hs_pginstall tsearch2 xyz00_abc" auf um in der Datenbank 
xyz00_abc die Funktionalität von tsearch2 zu installieren. Dann brauchen wir 
nicht in jeder Datenbank alle Funktionen und eventuellen Spezialtabellen, 
etc. mitschleppen.

Ich weiß nicht, welche Sprachen als sicher einzustufen sind. Die Programme, 
die ich bisher gesehen habe, verwenden z.B. C (sicher nicht sicher) nur in 
Standardmodulen, wie z.B. tsearch2. Die meisten, die eigene stored Procedures 
verwenden, nehmen gleich PL/SQL. Ich kenne eine Anwendung, die PL/Java 
verwendet (adempiere) und ich kann mich dunkel an ein paar erinnern, die 
PL/TCL und PL/Perl verwenden. PL/PHP wird meines Wissens so gut wie gar nicht 
verwendet, von PL/R und ähnlichen Exoten fange ich gar nicht erst an.

Meiner Meinung nach kann man auf die trusted Languages verzichten, wenn man 
Installationsskripte für die wichtigsten C Erweiterungen, wie z.B. tsearch2 
hat. Sonst wird nach meiner Erfahrung außer PL/SQL kaum etwas verwendet.

> abrechnungstechnisch sind sehr leistungsfähige Stored Procedures
> problematisch

Solche Stored Procedures kann man aber auch ohne weiteres in PL/SQL schreiben. 
Ich denke, dass ein paar Installationsskripte ohne weitere trusted Languages 
sinnvoll sind und auch abrechnungstechnisch keine Verschlechterung gegenüber 
dem Status Quo darstellen.

Die Alternative, die sich mir mit MediaWiki jetzt stellt ist, MySQL zu 
verwenden. Das braucht üblicherweise für die gleiche Funktionalität eher mehr 
Ressourcen als PostgreSQL, ist langsamer und bietet schlechtere 
Datensicherheit.

> P.S. Wie sieht das eigentlich im MySQL-Bereich aus?

MySQL unterstützt keine weiteren Sprachen: "A stored procedure is a set of SQL 
statements that can be stored in the server." 
(http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html)
Insofern stellt sich das Problem dort nicht.

Christof

-- 
actSoft gmbh                                 Software nach Maß

Zugspitzstr. 211                                www.actsoft.de
86165 Augsburg                                   cd at actsoft.de

                                      Registergericht Augsburg
Geschäftsführer                             Augsburg HRB 21896
Christof Donat                           UStID: DE 248 815 055