Peter T Mount wrote:
> On Wed, 5 Aug 1998, Bruce Momjian wrote:
>
> > > Peter,
> > >
> > > I have just finished up some other stuff in the backend, and I was
> > > wondering what to do next. My personal list include a cleanup of the lo
> > > type. Specifically:
> > >
> > > 1. Assign a fixed OID to the LO type so that attributes of this type
> > > can easily be identified.
> > >
> > > 2. Write a VACUUM LO procedure.
> > >
> > > 3. Extend/verify the existing internal lo functions to work with the
> > > new type.
> > >
> > > I know that more can/should be done in this area, but I only have so much
> > > time. I am aware the you have done some work on this in the contrib area.
> > > Were you planning on handling any (or all) of these issues as part of the
> > > 6.4 base release? I will gladly move on to something else.
> > >
> >
> > We should also make a large object type, rather than using inv_ to
> > identify it. It is on the TODO list, and I can implement it whenever
> > you want.
>
> agreed - although that would imply a different method of storing them. One
> of the problems I have with VACUUM LO is that using the existing oid
> method (for compatibility) would not work with the new type.
>
I see it that way also. But I do not perceive this to be a problem. Users who
have been using OIDs to link to their large_objects will continue to operate as
they always have. I can't see how we could attempt to promote the functionality
of existing install base. The problem, which is the essential problem, is that
we can presume nothing about the relationship between an arbitrary OID type column
and the large objects themselves.
However as part of a conversion, the DBA may be able to UPDATE pg_attribute
manually and change the type from OID to LO. ??? Or we provide a script to do
this where the DBA enters the large object columns???
> Either using a different form of storage, or a different prefix would sort
> this problem (the latter would be the easiest).
>
