Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id LAA47004
	for <pgsql-interfaces@postgreSQL.org>;
	Mon, 6 Dec 1999 11:09:02 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA18745;
	Mon, 6 Dec 1999 11:07:56 -0500 (EST)
To: dougt@mugc.cc.monash.edu.au
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Problems with postgres V6.5.3 large objects 
In-reply-to: Your message of Mon, 6 Dec 1999 20:35:00 +1100 (EST)
	<199912060935.UAA28036@mugca.cc.monash.edu.au>
Date: Mon, 06 Dec 1999 11:07:56 -0500
Message-ID: <18743.944496476@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Douglas Thomson <dougt@mugc.cc.monash.edu.au> writes:
>> Most of the developers have not wanted to put much effort into large
>> objects, since where we really want to go is to eliminate tuple size
>> restrictions; once that happens large objects will be much less
>> necessary.

> I am curious about the planned interface once tuple size restrictions
> are eliminated. I am using large objects, and want to make my
> application port as painlessly as possible.

This hasn't been thought about much, AFAIK.  I agree that with large
fields in tuples, it'd be nice to have operations that read or write
portions of fields, and also ways to read/write binary data without any
encoding.  But I'm not real sure what the API should look like.  Are
there precedents in other DBMSes?

			regards, tom lane