mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-20 23:13:22 +02:00
* Add option to build with OpenSSL out of the box. Fix thusly exposed bit rot. Although it compiles now, getting this to do something useful is left as an exercise. * Fix Kerberos options to defer checking for required libraries until all the other libraries are checked for. * Change default odbcinst.ini and krb5.srvtab path to PREFIX/etc. * Install work around for Autoconf's install-sh relative path anomaly. Get rid of old INSTL_*_OPTS variables, now that we don't need them anymore. * Use `gunzip -c' instead of g?zcat. Reportedly broke on AIX. * Look for only one of readline.h or readline/readline.h, not both. * Make check for PS_STRINGS cacheable. Don't test for the header files separately. * Disable fcntl(F_SETLK) test on Linux. * Substitute the standard GCC warnings set into CFLAGS in configure, don't add it on in Makefile.global. * Sweep through contrib tree to teach makefiles standard semantics. ... and in completely unrelated news: * Make postmaster.opts arbitrary options-aware. I still think we need to save the environment as well. |
||
---|---|---|
.. | ||
lo_drop.sql | ||
lo_test.sql | ||
lo.c | ||
lo.sql.in | ||
Makefile | ||
README.lo |
PostgreSQL type extension for managing Large Objects ---------------------------------------------------- Overview One of the problems with the JDBC driver (and this affects the ODBC driver also), is that the specification assumes that references to BLOBS (Binary Large OBjectS) are stored within a table, and if that entry is changed, the associated BLOB is deleted from the database. As PostgreSQL stands, this doesn't occur. It allocates an OID for each object, and it is up to the application to store, and ultimately delete the objects. Now this is fine for new postgresql specific applications, but existing ones using JDBC or ODBC wont delete the objects, arising to orphaning - objects that are not referenced by anything, and simply occupy disk space. The Fix I've fixed this by creating a new data type 'lo', some support functions, and a Trigger which handles the orphaning problem. The 'lo' type was created because we needed to differenciate between normal Oid's and Large Objects. Currently the JDBC driver handles this dilema easily, but (after talking to Byron), the ODBC driver needed a unique type. They had created an 'lo' type, but not the solution to orphaning. Install Ok, first build the shared library, and install. Typing 'make install' in the contrib/lo directory should do it. Then, as the postgres super user, run the lo.sql script. This will install the type, and define the support functions. How to Use The easiest way is by an example: > create table image (title text,raster lo); > create trigger t_image before update or delete on image for each row execute procedure lo_manage(raster); Here, a trigger is created for each column that contains a lo type. Issues * dropping a table will still orphan any objects it contains, as the trigger is not actioned. For now, precede the 'drop table' with 'delete from {table}'. However, this could be fixed by having 'drop table' perform an additional 'select lo_unlink({colname}::oid) from {tablename}' for each column, before actually dropping the table. * Some frontends may create their own tables, and will not create the associated trigger(s). Also, users may not remember (or know) to create the triggers. This can be solved, but would involve changes to the parser. As the ODBC driver needs a permanent lo type (& JDBC could be optimised to use it if it's Oid is fixed), and as the above issues can only be fixed by some internal changes, I feel it should become a permanent built-in type. I'm releasing this into contrib, just to get it out, and tested. Peter Mount <peter@retep.org.uk> June 13 1998