Re: [HACKERS] New pg_type for large object
От | Peter T Mount |
---|---|
Тема | Re: [HACKERS] New pg_type for large object |
Дата | |
Msg-id | Pine.LNX.3.95.980410194150.4819A-100000@maidast обсуждение исходный текст |
Ответ на | Re: [HACKERS] New pg_type for large object ("Kent S. Gordon" <kgor@inetspace.com>) |
Список | pgsql-interfaces |
On Fri, 10 Apr 1998, Kent S. Gordon wrote: [snip] > > The first is, that when we update the OID which points to the > > large object, the large object is orphaned. I realize that at > > the time of the update, we could select the old OID and > > subsequently drop the large object. The problem is that general > > purpose tools such as MS Access do not provide an clean > > framework for invoking such a query. Specifically, UPDATE > > statements would have to be torn apart to build such a SELECT > > statement. In the short term I can build a separate daemon to > > track down the orphans. I hope VACUUM will eventually handle > > these. > > You should be able to use triggers to fix the problem at the time that > the update statement is run. Yes that is one possibility, which I have done here, but this is a generic problem, rather than one unique to a single application. For triggers to work, you would have to add the trigger to each table, and to each column that may contain a large object. Also, triggers are not inherited. Creating a new lo/blob data type would make this transparent to the user, and would permit already written JDBC or ODBC based applications for other databases to work without modification. -- Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk Main Homepage: http://www.demon.co.uk/finder Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
В списке pgsql-interfaces по дате отправления: