Message-Id: <352D51A0.69CE8BB8@insightdist.com>
Date: Thu, 09 Apr 1998 18:54:24 -0400
From: David Hartwig <daveh@insightdist.com>
Organization: Insight Distribution Systems
Mime-Version: 1.0
To: pgsql-interfaces <pgsql-interfaces@postgreSQL.org>,
	PostgreSQL-development <hackers@postgreSQL.org>
Cc: Byron Nikolaidis <byronn@insightdist.com>
Subject: New pg_type for large object
Content-Type: multipart/mixed; boundary="------------493C6ADCB141A4B0F7C01648"

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.

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