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
thereferences 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 #
