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 #