After you have created and registered a user-defined function, your work is essentially done. Postgres, however, must load the object code (e.g., a .o file, or a shared library) that implements your function. As previously mentioned, Postgres loads your code at runtime, as required. In order to allow your code to be dynamically loaded, you may have to compile and link-edit it in a special way. This section briefly describes how to perform the compilation and link-editing required before you can load your user-defined functions into a running Postgres server. Note that this process has changed as of Version 4.2.
ユーザ定義関数を作成し、登録すれば、作業は終ったようなも のです。 しかし、Postgresはあなたの関数が実装さ れているオブジェクトコード(すなわち、.o ファ イル、もしくは共有ライブラリ)をロードしなくてはなりません。 前に述べたとおり、Postgres は あなたのコードを実行時に、必要に応じてロードします。 コードが動的にロードされるようにするためには、 特別な方法でコンパイルとリンクをしなくてはなりません。 この節では、実行中のPostgresサーバがあ なたのユーザ定義関数をロードできるようにするために、どのようにコ ンパイルとリンクをするかについて説明します。 この作業手順はバージョン 4.2 のときとは、変わっていることに注意し て下さい。
Tip: The old Postgres dynamic loading mechanism required in-depth knowledge in terms of executable format, placement and alignment of executable instructions within memory, etc. on the part of the person writing the dynamic loader. Such loaders tended to be slow and buggy. As of Version 4.2, the Postgres dynamic loading mechanism has been rewritten to use the dynamic loading mechanism provided by the operating system. This approach is generally faster, more reliable and more portable than our previous dynamic loading mechanism. The reason for this is that nearly all modern versions of UNIX use a dynamic loading mechanism to implement shared libraries and must therefore provide a fast and reliable mechanism. On the other hand, the object file must be postprocessed a bit before it can be loaded into Postgres. We hope that the large increase in speed and reliability will make up for the slight decrease in convenience.
古いPostgresの動的ローディング機構は、動的ロー ダを書く人が持つような、実行プログラムの形式やメモリ内での配置やアライ メントに関する深い知識を必要としていました。 そのようなローダは遅くて、バグが多くなりがちでした。 バージョン 4.2 において、Postgres 動的ロー ディング機構はオペレーティングシステムが提供する動的ローディング機構を 使うように書き直されました。 このアプローチにより、以前に我々が書いた動的ローディング機構に比べると、 全体に速く、堅牢で、移植性の良いものになりました。 その理由は、最近のバージョンのUNIXが共有ライブラリを実装するために動的 ローディング機構を使っており、それゆえに速くて堅牢な機構でなくてはなら ないからです。 他方、オブジェクトファイルはPostgresにロー ドされる前に、ちょっとした後処理をしなくてはなりません。 以前の訳では「前処理」になっていた 使い勝手がわずかに落ちることは、スピードと堅牢さの大幅なアップにより 埋め合わせできるのではないかと思います。
You should expect to read (and reread, and re-reread) the manual pages for the C compiler, cc(1), and the link editor, ld(1), if you have specific questions. In addition, the regression test suites in the directory PGROOT/src/regress contain several working examples of this process. If you copy what these tests do, you should not have any problems. The following terminology will be used below:
何か疑問が生じたら、Cコンパイラ cc(1) と、リンカ ld(1) の マニュアルページを(何度も何度も)読むべきです。 また、ディレクトリPGROOT/src/regress に入っている regression test 一式には、この処理に関して suites: ツール -> 一式というかんじかな。 動作する例がいくつか入っています。 これらのテストがしていることを真似れば、なにも問題は無いでしょう。 以下、次のような用語が使われます。
Dynamic loading is what Postgres does to an object file. The object file is copied into the running Postgres server and the functions and variables within the file are made available to the functions within the Postgres process. Postgres does this using the dynamic loading mechanism provided by the operating system.
動的ローディング とは Postgres がオブジェクトファ イルに対して行なうことです。 オブジェクトファイルは実行中の Postgres サーバの中にコピーされ、ファイル中の関数と変数は Postgres プロセス中の 関数として使えるようになります。 Postgres は、オペレーティングシステムが提供する動的ローディング機 構を使って、これを行ないます。
Loading and link editing is what you do to an object file in order to produce another kind of object file (e.g., an executable program or a shared library). You perform this using the link editing program, ld(1).
ローディングとリンク処理 とは、なにか他の種類のオブジェクトファイル(たとえば、実行モ ジュールや共有ライブラリ)を作るために、オブジェクトファイル に対して行なうことです。 これはリンカ ld(1) を使って行ないます。
The following general restrictions and notes also apply to the discussion below:
次に述べる一般的な制限や注意事項は、後述する説明においても適用されます。
Paths given to the create function command must be absolute paths (i.e., start with "/") that refer to directories visible on the machine on which the Postgres server is running.
関数作成コマンドのパスは Postgres サーバの走るマシンから 見えるディレクトリを参照する 絶対パス(すなわち "/" で始まる)でなくてはなりません。
Tip: Relative paths do in fact work, but are relative to the directory where the database resides (which is generally invisible to the frontend application). Obviously, it makes no sense to make the path relative to the directory in which the user started the frontend application, since the server could be running on a completely different machine!
相対パスも実際には使えますが、データベースがあるディレクトリ(ふつうフ ロントエンドアプリケーションからは見えません)に対して相対的なものになります。 サーバは全く別のマシンで実行することもできるのですから、 ユーザがフロントエンドアプリケーションを起動したディレクトリ に対して相対的なパスを定義することは、明らかに無意味です。
The Postgres user must be able to traverse the path given to the create function command and be able to read the object file. This is because the Postgres server runs as the Postgres user, not as the user who starts up the frontend process. (Making the file or a higher-level directory unreadable and/or unexecutable by the "postgres" user is an extremely common mistake.)
Postgres ユーザ [1] は関数生成 コマンドのパスにアクセス可能であり、オブジェクトファイルが読み込み 可能でなくてはなりません。 なぜなら、Postgres サーバは Postgres ユーザとして実行するのであ って、フロントエンドプロセスの起動ユーザとしてではないからです。 (ファイルやその上のレベルのディレクトリを Postgres ユーザから読み込み不可もし くは実行不可にしてしまうのは、非常に良くあるミスです。)
Symbol names defined within object files must not conflict with each other or with symbols defined in Postgres.
オブジェクトファイル内のシンボル名は、互いに、かつ Postgres が定義したシンボルとも 衝突してはいけません。
The GNU C compiler usually does not provide the special options that are required to use the operating system's dynamic loader interface. In such cases, the C compiler that comes with the operating system must be used.
GNU C コンパイラは、通常はオペレーティングシステムの動的ローデ ィングインターフェースを使うための特別なオプションがありません。 そのような場合には、オペレーティングシステムが提供する C コン パイラーを使って下さい。
It is very easy to build dynamically-loaded object files under ULTRIX. ULTRIX does not have any shared library mechanism and hence does not place any restrictions on the dynamic loader interface. On the other hand, we had to (re)write a non-portable dynamic loader ourselves and could not use true shared libraries. Under ULTRIX, the only restriction is that you must produce each object file with the option -G 0. (Notice that that's the numeral ``0'' and not the letter ``O''). For example,
ULTRIXで動的ロード可能なオブジェクトファイルを作るのは、とても簡 単です。 ULTRIXは共有メモリ機構を持っていませんが、それゆえ、動的ローディ ングインターフェースに対して、なにも制約を設けていません。 一方、我々は移植性の無いダイナミックローダを我々自身で(再度)書か ねばならなかったし、本当の共有ライブラリを使うこともできませんで した。 ULTRIXにおいて、唯一の制限はオブジェクトファイルを作成する時に オプション -G 0 を使わなれけばならないということです。 (数字の ``0'' であり、文字の ``O''ではないことに注意)。 例えば、
# simple ULTRIX example % cc -G 0 -c foo.cproduces an object file called foo.o that can then be dynamically loaded into Postgres. No additional loading or link-editing must be performed. これは、foo.o という名前で Postgresに動的ロ ーディングできるオブジェクトファイルを生成します。 この他に追加のローディングやリンク処理をする必要はありません。
| [1] | (訳註)このPostgres ユーザとは、サー バを起動するユーザ(通常は postgres )のことです。 |