Re: [HACKERS] New pg_type for large object

>>>>> "daveh" == David Hartwig <daveh(at)insightdist(dot)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(at)insightdist(dot)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(at)inetspace(dot)com