Re: tuptoaster.c must *not* use SnapshotAny

Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > >
> > > Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > >
> > > > For example is it possible to update a toast
> > > > chunk partially using SnapshotToast ?
> > >
> > > As things stand (with either SnapshotToast or the old SnapshotAny way)
> > > it is never possible to update an individual toast value, either
> > > partially or wholly. All you can do is lay down a new toast value (with
> > > a new identifying OID) and then delete the old one.
> > >
> > > But I'm not sure that this is wrong, or fixable. Trying to update part
> > > of a toasted value is very much like wanting to update part of an
> > > existing row in-place, which we cannot possibly do.
> >
> > Bytea seems to be considered as a candidate for BLOB
> > though I think the entirely new type is preferable.
> > It seems impossible to implement a functionality like
> > inv_write using bytea which the current large object
> > stuff has.
>
> Agreed. I think that was the reason we kept TOAST and large objects,
> because large objects were designed for random read-write. If we can
> get large objects to auto-delete, probably with pg_depend, we can then
> use them seamlessly with BLOB I/O routines.

Oops I seem to have missed the discussion about excluding
bytea from the candidate from BLOB. Yes now we seem to have
a good reason to exclude existent type from the candidate
of BLOB.

regards,
Hiroshi Inoue