Bruce Momjian wrote:<br /><blockquote cite="mid:200106110315.f5B3FgT24983@candle.pha.pa.us" type="cite"><blockquote
type="cite"><prewrap="">Thomas Swan <a class="moz-txt-link-rfc2396E"
href="mailto:tswan@olemiss.edu"><tswan@olemiss.edu></a>writes:<br /></pre><blockquote type="cite"><pre wrap="">I
knowthat BLOBs are on the TODO list, but I had an idea.<br /></pre></blockquote><pre wrap="">I think you just
rediscoveredTOAST.<br /></pre></blockquote><pre wrap=""><br />We have TOAST and people want to keep large objects for
performance. I<br />think we could us an API that allows TOAST binary access and large<br />object access using the
sameAPI, and hopefully an improved one.</pre></blockquote> I think I missed what I was trying to say in my original
statement. I think there's a way to use the existing API with performance benefits left intact.<br /><br /> Take for
examplethe table :<br /><tt>create table foo {</tt><tt><br /></tt><tt> foo_id serial,</tt><tt><br /></tt><tt>
foo_namevarchar(32),</tt><tt><br /></tt><tt> foo_object BLOB,</tt><tt><br /></tt><tt>);</tt><tt><br /></tt><br /> On
theinsert statement <tt>"insert into foo (foo_name,foo_object) values ('My Object','{some escaped arbitrary string of
binarydata}');"</tt>, flush the {some escaped arbitrary string of binary data} to disk as a temporary file. Then do
thelo_import operation transparent to the user.<br /><br /> On a select, do the same thing (transparently) and return
thedata back to user.<br /><br /> Personally, I like LO's being stored separately from the actual table.<br /><br /><br
/><br/>
