Re: [HACKERS] SPI procedure for removing large objects
От | Peter T Mount |
---|---|
Тема | Re: [HACKERS] SPI procedure for removing large objects |
Дата | |
Msg-id | Pine.LNX.3.96.980805220222.793B-100000@maidast.retep.org.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] SPI procedure for removing large objects (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] SPI procedure for removing large objects
|
Список | pgsql-hackers |
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. Either using a different form of storage, or a different prefix would sort this problem (the latter would be the easiest). > > -- > Bruce Momjian | 830 Blythe Avenue > maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 > + If your life is a hard drive, | (610) 353-9879(w) > + Christ can be your backup. | (610) 853-3000(h) > -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
В списке pgsql-hackers по дате отправления: