ここでの答えは「複雑です」です。実際には、手続き型言語(pl / javaを含む)でかなり遠くまで行くことができますが、Cで得られる柔軟性を得ることができません。根本的に欠けているのは、PL/Javaで適切なインデックス作成サポートを実行できることです。新しいプリミティブを作成できません。ほとんどの例はpl/pgsqlにありますが、もう少し詳しくは、私のブログをご覧ください。
タイプ
これで、実際にはPL / Java(またはPL / Perl、PL / Python、またはその他の好きなもの)で非常に遠くまで行くことができますが、手の届かないものがいくつかあります。これは、dbの手続き型言語で何が可能で何が不可能かについての非常に高い概要でもあります。
手続き型言語で型を操作する効果的な方法は2つあります。ドメイン(プリミティブのサブタイプ)を操作することも、複合型(プリミティブ、ドメイン、または複合型自体のいずれかの別の型であるプロパティを持つオブジェクト)を操作することもできます。一般に、複合型自体のインデックス付けに関しては、実際には多くのことを行うことはできませんが、それらのメンバーにインデックスを付けることはできます。安全ではないもう1つのことは出力フォーマットですが、これを置き換える他の関数を提供することができます。
たとえば、PNGファイルを保存し、データベース内の特定のプロパティに対してそれらを処理するためのタイプが必要だとします。これは次の方法で行うことができます。
CREATE DOMAIN png_image as bytea check value like [magic number goes here];
次に、さまざまな方法でpngを処理するための一連のストアドプロシージャを作成できます。たとえば、関数is_sunsetの上部にあるオレンジを探すことができます。次のようなことができるかもしれません:
SELECT name FROM landmark l
JOIN landmark s ON (s.name = 'San Diego City hall'
and ST_DISTANCE(l.coords, s.coords) < '20')
WHERE is_sunset(photo)
ORDER BY name;
is_sunsetがJava、Perl、またはその他の好きな言語で処理できなかった理由はありません。is_sunsetはboolを返すため、次のこともできます。
CREATE INDEX l_name_sunset_idx ON landmark (name) where is_sunset(photo);
これにより、夕焼けの写真の名前のインデックスをキャッシュできるようになるため、クエリが高速化されます。
Javaでできないことは、新しいプリミティブ型を作成することです。インデックスのサポートなどはプリミティブレベルであるため、たとえば、GiSTインデックスをサポートする新しいIPアドレスタイプを作成することはできません(ip4rが利用可能であるため、作成する必要はありません)。
したがって、再利用して既存のプリミティブを操作できる範囲で、Javaまたは任意の方法で開発を行うことができます。あなたは実際に利用可能なプリミティブによってのみ制限されており、十分な数の人々がCで新しいプリミティブを作成しているので、これらに触れる必要はまったくないかもしれません。
インデックス
インデックスコードは、プリミティブと同様にほとんどCのみです。手続き型言語でインデックスの動作をカスタマイズすることはできません。あなたができることは、他の開発者のプリミティブなどを操作することです。これは、Cにドロップする必要がある可能性が最も高いエリアです。
(更新:私が考えると、既存のインデックスタイプにフックして、CREATE OPERATOR CLASS
およびCREATE OPERATOR
コマンドを使用して、他のPL関数に基づくさまざまなインデックスのサポートを追加できる可能性があります。これを行った経験はありません。)
パフォーマンス
PL / Javaは、各バックエンドプロセスでJVMを実行していることを意味することに注意してください。多くの場合、pl / pgsqlでやりたいことを実行できれば、パフォーマンスが向上します。もちろん、他の言語にも同じことが言えます。バックエンドプロセスにはインタプリタまたは他の環境が必要だからです。