Re: [INTERFACES] New pg_type for large object

On Thu, 9 Apr 1998, David Hartwig wrote:

> Greetings,
>
> We are putting the finishing touches on some enhancements to the ODBC
> driver.   One  feature, in particular, uses large objects to implement
> OLE data types.   We are rather please with the way it is working.   Via
> MS Access, we have been able to INSERT and SELECT objects, such as VISIO
> drawings, Word Documents, and WAV sound clips.    However, we've run
> into two problems.
>
> The first is, that when we update the OID which points to the large
> object, the large object is orphaned.  I realize that at the time of the
> update, we could select the old OID and subsequently drop the large
> object.  The problem is that general purpose tools such as MS Access do
> not provide an clean framework for invoking such a query.
> Specifically, UPDATE statements would have to be torn apart to build
> such a SELECT statement.  In the short term I can build a separate
> daemon to track down the orphans.   I hope VACUUM will eventually handle
> these.
>
> The second, and more difficult, problem is that there is no large object
> data type.  When we gather table info in the driver we have no idea that
> an OID may actually be a large object.   What we need is a large object
> data type.  Furthermore, the data type must have a stable OID so the we
> can recognize it when we gather table info.  We have tested the driver
> by creating our own date type.  However, with the existing function
> scoping of our driver, it is extremely difficult to dynamically locate a
> user defined large object data type.    So for testing we have compiled
> in our "lo" data type OID.
>
> What I would like to know is, can a large object data type be added as
> an internal data type?    The various "lo_" functions should eventually
> be overloaded (or modified) to be able to use this data type.   But it
> is not necessary at this time.  I believe this addition is a very low
> risk change, and I would very much like to get to have it in the 6.3.2
> release for distribution.   May I submit the patch, or would someone
> kindly hack it in for us?

I've actually started to look at this for JDBC, as it too has the orphan
problem. I went down two routes. One using triggers, but that had the
problem that triggers are not inherited, so I started to look at rules.

However, as usual, my pay job had to take precidence, so I was about to
start looking at it today.

I'd like to see your solution to this.

--
Peter T Mount  petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk