DEC OSF/1

Under DEC OSF/1, you can take any simple object file and produce a shared object file by running the ld command over it with the correct options. The commands to do this look like:

DEC OSF/1 では、正しいオプションを指定して ld コマンドを実行する ことで、単純オブジェクトファイルと共有オブジェクトファイルを作 ることができます。 これを実行するコマンドは次のとおりです。

# simple DEC OSF/1 example
% cc -c foo.c
% ld -shared -expect_unresolved '*' -o foo.so foo.o
The resulting shared object file can then be loaded into Postgres. When specifying the object file name to the create function command, one must give it the name of the shared object file (ending in .so) rather than the simple object file. 結果としてできる共有オブジェクトファイルは Postgresにロードできるように なります。 関数生成コマンドに対してオブジェクトファイル名を指定する時には、 単純オブジェクトファイルではなく、共有オブジェクトファイル (拡 張子が .so ) を指定しなくてはなりません。

Tip: Actually, Postgres does not care what you name the file as long as it is a shared object file. If you prefer to name your shared object files with the extension .o, this is fine with Postgres so long as you make sure that the correct file name is given to the create function command. In other words, you must simply be consistent. However, from a pragmatic point of view, we discourage this practice because you will undoubtedly confuse yourself with regards to which files have been made into shared object files and which have not. For example, it's very hard to write Makefiles to do the link-editing automatically if both the object file and the shared object file end in .o!

事実上、 Postgres は それが共有オブジェクトファイルである限り、どんな名前をつけても関与しません。 あなたが共有オブジェクトファイルの拡張子として .o のほうを好むならば、 正しいファイル名が関数生成コマンドに与えられる限り、 Postgresはそれを受け入れます。 要するに、つじつまを合わせなさいということです。 しかし、現実的な観点からすれば、どれを共有オブジェクトファイルとして作成し、 どれをそうでなくしたかについて、きっと混乱することになるので、こういう方法は勧められません。 たとえば、オブジェクトファイルと共有オブジェクトファイルの名前が両方とも .o で終るとすると、リンク処理を自動で行なうような Makefile を書くの はとても大変です!

If the file you specify is not a shared object, the backend will hang! もし、あなたの指定するファイルが共有オブジェクトでないと、バックエンド はハングするでしょう!