From: | Peter T Mount <peter(at)retep(dot)org(dot)uk> |
---|---|
To: | David Hartwig <daveh(at)insightdist(dot)com> |
Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, serg(at)gate(dot)informika(dot)ru, hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] SPI procedure for removing large objects |
Date: | 1998-08-06 05:45:16 |
Message-ID: | Pine.LNX.3.96.980806064239.793F-100000@maidast.retep.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 5 Aug 1998, David Hartwig wrote:
>
>
> 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.
Actually, if what Bruce is saying about LO then this problem may go away.
> 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???
I don't think it would hurt to have a script to to the conversion -
especially for those who are upgrading existing databases.
> > Either using a different form of storage, or a different prefix would sort
> > this problem (the latter would be the easiest).
> >
--
Peter T Mount peter(at)retep(dot)org(dot)uk or petermount(at)earthling(dot)net
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
From | Date | Subject | |
---|---|---|---|
Next Message | Peter T Mount | 1998-08-06 05:47:14 | Re: [HACKERS] SPI procedure for removing large objects |
Previous Message | Peter T Mount | 1998-08-06 05:34:55 | Re: [HACKERS] CVS and the backend |