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 |/
