Alex Pilosov wrote:
>
> On Wed, 27 Jun 2001, Hannu Krosing wrote:
>
> > Bruce Momjian wrote:
> > >
> > > > Bruce Momjian wrote:
> > > > >
> > > > > > Please, consider a BLOB column type without having to do lo_import,
> > > > > > lo_export.
> > > > >
> > > > > Yep, big needed item.
> > > >
> > > > as we have now and unlimited rowlength it seems to be more of an
> > > > interface issue than the actual implementation one (mod seek/read).
> > > >
> > > > Is there an ISO/ANSI SQL interface to BLOB's defined someplace ?
> > >
> > > Yes, clearly interface. Someone is working on code to insert/export
> > > binary stuff using bytea and base64 encoding. Seems like a good idea.
> >
> > Will there also be support current file-like BLOB ops like seek and
> > read(n) ?
>
> Sure, via substring().
That would _not_ be seek()+read() by default but can be possibly
implemented
as such in cooperation with toast machinery.
> Unfortunately, TOASTed tuple must be detoasted
> completely, and you cannot get any performance boost by, for example,
> reading first 8k out of a 500k bytea value. All 500k must be detoasted
> first.
I suspect that this can be avoided with a smarter toast-aware substring
and possibly also disallowing compression (just using spreading overs
multiple toast-table records).
IIRC there exists machinery (if not interface) for influencing TOAST
processor
decisions to compress or not.
AFAIK, oracle LONGs have some smart schema where you can acess them in
some
smart ways if the cursor is on current row, but you will get full
bytestrings
if you request more than one row at a time, i.e. some compined BLOB/LONG
scheme.
I think this is worth considering, specially for seek/read/write type
operations.
--------------
Hannu
