Received: from soccer.inetspace.com (soccer.inetspace.com [206.50.163.48]) by
	hub.org (8.8.8/8.7.5) with ESMTP id LAA24785;
	Fri, 10 Apr 1998 11:34:17 -0400 (EDT)
Received: (from kgor@localhost)
	by soccer.inetspace.com (8.8.7/8.8.7) id KAA10774;
	Fri, 10 Apr 1998 10:32:38 -0500 (CDT) (envelope-from kgor)
Date: Fri, 10 Apr 1998 10:32:38 -0500 (CDT)
Message-Id: <199804101532.KAA10774@soccer.inetspace.com>
From: "Kent S. Gordon" <kgor@inetspace.com>
To: daveh@insightdist.com
CC: pgsql-interfaces@postgreSQL.org, hackers@postgreSQL.org,
	byronn@insightdist.com
In-reply-to: <352D51A0.69CE8BB8@insightdist.com> (message from David Hartwig
	on Thu, 09 Apr 1998 18:54:24 -0400)
Subject: Re: [HACKERS] New pg_type for large object

>>>>> "daveh" == David Hartwig <daveh@insightdist.com> writes:

    > This is a multi-part message in MIME format.
    > --------------493C6ADCB141A4B0F7C01648 Content-Type: text/plain;
    > charset=us-ascii Content-Transfer-Encoding: 7bit

    > 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.

You should be able to use triggers to fix the problem at the time that 
the update statement is run.

    > 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?

    > Great work!


    > --------------493C6ADCB141A4B0F7C01648 Content-Type:
    > text/x-vcard; charset=us-ascii; name="vcard.vcf"
    > Content-Transfer-Encoding: 7bit Content-Description: Card for
    > David Hartwig Content-Disposition: attachment;
    > filename="vcard.vcf"

    > begin: vcard fn: David Hartwig n: Hartwig;David email;internet:
    > daveh@insightdist.com x-mozilla-cpt: ;0 x-mozilla-html: FALSE
    > version: 2.1 end: vcard


    > --------------493C6ADCB141A4B0F7C01648--

-- 
Kent S. Gordon
Architect
iNetSpace Co.
voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com