I have added to TODO:
o -Add non-large-object binary field (already exists -- bytea)
o -Make binary interface for TOAST columns (base64)
o Improve vacuum of large objects (/contrib/vacuumlo)
o Add security checking for large objects
o Make file in/out interface for TOAST columns, similar to large object
interface (force out-of-line storage and no compression)
o Auto-delete large objects when referencing row is deleted
> Can this be added to the TODO list? (actually put back on the TODO list)
> Along with this email thread?
> I feel that it is very important to have BLOB support in postgres that
> is similar to what the commercial databases provide. This could either
> mean fixing the current implementation or adding additional capabilities
> to toasted columns.
> The major problem with the current LargeObject implementation is that
> when the row containing the LargeObject is deleted the LargeObject
> isn't. This can be a useful feature under some circumstances, but it
> isn't how other databases handle BLOBs. Thus porting code from other
> databases is a challenge. While it is true that this can be worked
> around through triggers, I don't like the manual nature of the workarounds.
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >>>Offhand this seems like it would be doable for a column-value that
> >>>was actually moved out-of-line by TOAST, since the open_toast_object
> >>>function could see and return the TOAST pointer, and then the read/
> >>>write operations just hack on rows in pg_largeobject. The hard part
> >>I am confused how pg_largeobject is involved?
> > s/pg_largeobject/toast_table_for_relation/ ... sorry about that ...
> >>Don't forget compression of TOAST columns. How do you fseek/read/write
> >>in there?
> > Well, you can *do* it, just don't expect it to be fast. The
> > implementation would have to read or write most of the value, not just
> > the segment you wanted. A person who actually expected to use this
> > stuff would likely want to disable compression on a column he wanted
> > random access within.
> > Hmm ... that provides an idea. We could easily add some additional
> > 'attstorage' settings that say *all* values of a column must be forced
> > out-of-line (with or without allowing compression), regardless of size.
> > Then, open_toast_object would work reliably on such a column. One
> > possible user API to such an infrastructure is to invent BLOB and CLOB
> > datatypes, which are just like bytea and text except that they force the
> > appropriate attstorage value. Ugly as sin, ain't it ... but I bet it
> > could be made to work.
> > Okay, there's your idea. Now, who can do better?
> > regards, tom lane
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> > http://www.postgresql.org/search.mpl
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2001-09-06 20:41:33|
|Subject: Re: Idea for nested transactions / savepoints|
|Previous:||From: Bruce Momjian||Date: 2001-09-06 20:11:40|
|Subject: Re: TRUNCATE question|