Quoting Tom Lane <[EMAIL PROTECTED]>: > Network Administrator <[EMAIL PROTECTED]> writes: > > The abstraction I am talking about would be a logical layer that would > handle > > disk I/O including the format of that data (lets call this the ADH). > > This sounds good in the abstract, but I don't see how you would define > such a layer in a way that was both thin and able to cope with large > changes in representation. In a very real sense, "handle disk I/O > including the format of the data" describes the entire backend. To > create an abstraction layer that will actually give any traction for > maintenance, you'd have to find a way to slice it much more narrowly > than that.
*nod* I thought that would probably be the case. The "thickness" of that layer would be directly related to how the backend was sliced. However it seems to me that right now that this might not be possible while the backend is changing between major releases. Perhaps once that doesn't fluxate as much it might be feasible to create these layer so that it is not too fat. Maybe the goal is too aggressive. To ask (hopefully) a simpler question. Would it be possible to at compile time choose the on disk representation? I'm not sure but I think that might reduce the complexity since the abstraction would only exist before the application is built. Once compiled there would be no ambiguity in what representation is chosen. > Even if the approach can be made to work, defining such a layer and then > revising all the existing code to go through it would be a huge amount > of work. > > Ultimately there's no substitute for hard work :-( > > regards, tom lane True, which is why I've never been bothered about going through a process to maintain my database's integrity and performance. However, over time, that across my entire client base I will eventually reach a point where I will need to do an "in place" upgrade or at least limit database downtime to a 60 minute window- or less. -- Keith C. Perry Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
