Re: heap_create with OID? (fwd)

If anyone was following my request to have a large object api for TOAST,
this is of interest.

--
  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
Tom Lane wrote:
> My own feeling is that the current LO setup is fundamentally flawed
> by its reliance on specific OID values, and that the right answer is
> to find a way to avoid that.  contrib/lo might provide some food for
> thought here (although it's clearly not the whole answer either).

    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.   The  file  I/O itself can be based on the fastpath
    interface.

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

    All  LO's  for  one  base  table  can  be  stored in one big,
    segmented external heap (more or less like toast values). The
    system would automatically know when objects are obsolete.

    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.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #