This relates to large objects too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

At 14:41 4/07/00 +0200, Jan Wieck wrote:
>Tom Lane wrote:
>
>    I  have  some  ideas  to  replace  the  entire LO handling by
>    something completely  different.  More  compatible  with  the
>    Oracle  way  of  handling  large  objects.  That  is, that on
>    INSERT/UPDATE  someone  uses  a  function  to  place  an   LO
>    reference  into  the  tuple.  Then  having a new interface in
>    libpq, that works like file I/O on the references that appear
>    in a result set. To open them for writing, the user must have
>    selected them for update, otherwise  he  can  open  them  for
>    reading.  

It might be worth looking at the SQL standard and it's 'locators' for BLOB
data. They sound a lot like this, but may have some requirements that
affect your design.


> The  file  I/O itself can be based on the fastpath
>    interface.

What's the 'fastpath interface'?


>    The LO's follow Oracles copy semantic,  so  if  someone  does
>    INSERT ... SELECT, the LO gets duplicated.

Great. The standard seems (by default) to treat them as just another
'value', which this is consistent with. It may be relevant to mention that
the standard also allows substr, ||, etc to work on BLOBs.


>    An  INSERT  operation  might  then  return a result set as if
>    someone did a SELECT FOR  UPDATE  of  exactly  what  he  just
>    inserted.   So he immediately has access to the LO references
>    to place the values.
>
>    Don't know yet how to interface it from psql  -  but  let  me
>    sleep another night or so over it.

FWIW, Dec/Rdb uses a kind of cursor for the BLOB data. The row insert must
be done in a normal insert cursor, then another cursor is opened to write
the BLOB data. It's very cumbersome. But if you use an insert cursor for
your table rows, then at least you do have a context available for BLOB
insertion.



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/
Tue, 10 Oct 2000 21:08:51 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: heap_create with OID? (fwd)