This page refers to ancient software, which I still provide for those that are still interested. However, my development efforts have migrated from PostgreSQL to FrontBase which I find to be a better database in general for the majority of applications.
For those that are interested in using the PostgreSQL database from EOF, I have provided a completely unsupported adaptor. Currently, there is only one NEXTSTEP port of Postgres95, but this is an old version of the database. No one has yet ported the latest release of PostgreSQL to OPENSTEP. o
I have created an EOF 1.1 adaptor for NEXTSTEP 3.3 which works with the old version of the Postgres95 database. I have also created an EOF 1.2 adaptor for OPENSTEP 4.1 which works with the latest PostgreSQL database. Note that to use the OPENSTEP adaptors one must also download the PostgreSQL Framework (71762) which is the libpq library ported to OPENSTEP as a Framework. This Framework is based on the 6.1 beta code dated 970405. Each of the OPENSTEP Frameworks is designed to be installed into /LocalLibrary/Frameworks.
Note that there currently seems to be a problem with the 6.0 backend when using large objects. The EOF 2.x adaptor should work properly, assuming the backend does not crash. However, under my test conditions, the backend always crashes after inserting a large object. There has been work done in the area of large objects for the 6.1 release. When that release reaches the light of day I will attempt to test my adaptor more.
|EOF 1.1||EOF 1.2||EOF 2.x|
|NEXTSTEP 3.3 Intel||v0.50 alpha (71043)|
|NEXTSTEP 3.3 NeXT||v0.50 alpha (70489)|
|NEXTSTEP 3.3 HPPA||v0.50 alpha (87867)|
|NEXTSTEP 3.3 Sparc||v0.50 alpha (84782)|
|NEXTSTEP 3.3 QuadFat||v0.50 alpha (291667)|
|OPENSTEP 4.1 TriFat||v0.50 alpha (54574)||v0.50 alpha (62259)|
All files have been compressed using gnutar and gzip. Each entry shows the version and (byte count) of the compressed file.
The adaptor supports only a subset of Postgres95 capabilities.
Large object support is limited. The assumptions are that any oid field in the database really contains a large object identifier. This identifier is used to generate the contents of an NSData. Therefore, large objects can not be used as part of a primary key, and cannot have the locked property set, and do not qualify a query using an oid field.
Note that if you are using the NEXTSTEP port of Postgres95 or another database that is about as old as that port, you will get warnings generated when using EOModeler. This is because there is an error in the database that does not allow the proper processing of "abort transaction" commands. This is not a problem, as the adaptor still works.
Please email Scott Harrison if you have any comments. Of course, as totally unsupported software, you are not guaranteed any response. Enjoy.