Currently, POSTGRES is about 90,000 lines of code in C and is being used by assorted "bold and brave" early users. The system has been constructed by a team of 5 part time students led by a full time chief programmer over the last three years. During this period, we have made a large number of design and implementation choices. Moreover, in some areas we would do things quite differently if we were to start from scratch again. The purpose of this paper is to reflect on the design and implementation decisions we made and to offer advice to implementors who might follow some of our paths. In this paper we restrict our attention to the DBMS "backend" functions. In another paper some of us treat PICASSO, the application development environment that is being built on top of POSTGRES. 1. INTRODUCTION Current relational DBMSs are oriented toward efficient support for business data processing applications where large numbers of instances of fixed format records must be stored and accessed. Tr...

Abstract not found

We present a user interface paradigm for database management systems that is motivated by scienti c visualization applications. Our graphical user interface includes a \boxes and arrows" notation for database access and a ight simulator model of movement through information space. We also provide means to specify a hierarchy of abstracts of data of di erent types and resolutions, so that a \zoom " capability can be supported. The underlying DBMS support for this system is described and includes the compilation of query plans into megaplans, new algorithms for data bu ering, and provisions for a guaranteed rate of data delivery. The current state of the Tioga implementation is also described.

Oberon [ReWi92] and Oberon-2 [MöWi91] are general purpose programming languages in the tradition of Pascal and Modula-2. Oberon [WiGu89] is also a modular, single-threaded operating system for single-user operation of workstations. It is used in daily work as well as in programming courses. One missing point of Oberon is the existence of database functionality such as persistence or recovery. This report describes the project Oberon-D, which adds database functionality to the Oberon system. The first step of this project is to include persistence, i.e., the object's property to outlive the programs that create it. Persistence in the Oberon system is obtained by a persistent heap on the disk. Persistent objects are on this heap, while transient objects are in the transient memory. Transient and persistent objects can access each other mutually. Accessing a persistent object leads to loading the object into the transient heap. If they are not accessed from transient objects any more, the...