Re: 7.2 items
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.
--
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 19026Import Notes
Reply to msg id not found: 3B38AE17.5B0B2811@tm.ee
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) ?
----------------
Hannu
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(). 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.
-alex
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