Nach längerer Zeit gibt es wieder etwas über neue Features der sQLshell zu berichten: Der SQL-Texteditor versteht neue syntaktische Konstrukte.

Bei den Erweiterungen handelt es sich um solche, die das Verhalten vor der Ausführung der SQL-Fragmente im Editor beeinflussen: sie werden vor dem Versand der Statements an die jeweilige Datenbank rückstandslos aus dem SQL-Fragment entfernt, bzw durch gültige SQL-Standard-Elemente ersetzt:

Beim Ausführen von SQL-Fragmenten aus dem Texteditor verfährt die sQLshell normalerweise wie folgt: Das Textfragment wird aus dem Editor extrahiert - das ist entweder der gesamte Text oder - falls der Anwender einen Teil des Textes selektiert hat - der selektierte Text. Dieser wird an den Semikolons in einzelne Statements zerlegt. Sämtliche SQL-Kommentare werden entfernt und auch alle Zeilenende-Zeichen. Anschließend sendet die sQLshell alle separierten Statements einzeln zur Ausführung an die Datenbank.

Dieses Vorgehen ist hinderlich, wenn zum Beispiel Stored Procedures bearbeitet werden sollen. Daher wurde die sQLshell erweitert: Bilden die Zeichen §§ den Anfang eines SQL-Fragmentes, wird bis auf das Abschnieden dieser beiden Zeichen keine Modifikation vorgenommen, sondern das Fragment genau so an die Datenbank gesendet, wie es im Texteditor vorlag.

Die zweite Ergänzung syntaktischer Konstrukte half bei der Durchführung einer Reihe von Tests mit Large Objects in Postgres: Der Standard JDBC (das die sQLshell nutzt, um maximale Interoperabilität mit möglichst vielen Datenbanken zu bieten) bietet keine Möglichkeiten, mit diesen zu interagieren. Wenn man das Connection-Objekt zur Datenbank aber als Postgres-spezifische Connection benutzt, kann man sehr einfach Large Objects manipulieren. In Postgres ist es nun so, dass der Import einer größeren Anzahl von Large Object kompliziert ist: Es funktioniert nur auf dem Server, man muss Administrator-Rechte auf dem Server haben... Einfacher geht es, wenn man am Client das API benutzt. Gesagt, getan: Ich habe ein kleines BeanShell-Skript geschrieben, das einen Dateiauswahldialog öffnet, den Inhalt der Datei in ein Large Object packt und die erzeugte OID ausgibt. Dann kam die zündende Idee: Wenn man Skripte zur Ausführung in Standard-SQL einbauen könnte, die vor dem Absenden an die Datenbank ausgeführt würden?

Dafür ist es nötig, in eine SQL-Anweisung den Skriptnamnen eingeschlossen in "${" und "}" einzutragen. Dieser Ausdruck wird vor dem Versand an die Datenbank durch das Ergebnis des Skripts ersetzt. Ein kleines Beispiel soll das verdeutlichen:

return 123;

Dieses Beanshell-Skript gespeichert unter dem Namen /tmp/test.bsh würde dafür sorgen, dass folgendes SQL-Statement

select ${/tmp/test.bsh}

das Ergebnis

123

liefert. Dieses neue Feature befindet sich aktuell in der Erprobung - nach der alten Weisheit aus dem Amiga-Magazin "Fehlt Dir was? Programmier Dirs doch!" fühlt sich dieses neue Feature aktuell sehr mächtig an und verspricht eine ganze Welt voller neuer Möglichkeiten für die sQLshell zu erschließen.

Zum Abschluss sind hier noch die drei Skripte angehängt, mit denen die Large-Object-Tests durchgeführt wurden.

Lizenz

pg_lo_import_existing_oid

pg_lo_import_new_oid

pg_lo_export_for_oid

Artikel, die hierher verlinken