robe@wmt.UUCP (Rob van den Berg) (04/18/88)
Can someone give me references regarding POSTGRES, an object oriented extension ( alternative? ) of INGRES. Please respond by E-mail. I will summarize to the net. Rob van den Berg. -------------------------------------------------------------------- Rob van den Berg USENET: robe@wmt.uucp Westmount Technology BV tel: +31 15 569224 (Office) Poortweg 4, 2612 PA Delft +31 10 4552841 (Home) the Netherlands -------------------------------------------------------------------- -- Rob van den Berg tel: +31 15 569224 WestMount Technology B.V. email: robe@wmt Poortweg 4 2612 PA Delft, the Netherlands
ananth@mandrill.CWRU.Edu (ananth srinivasan) (04/29/88)
Does anyone know if there is a version of POSTGRES that is available and can be purchased? What hardware environments does it run on? Details would be appreciated. Anyone from RTI out there?? Please e-mail your replies.
larry@postgres.uucp (Larry Rowe) (05/03/88)
In article <2458@mandrill.CWRU.Edu> ananth@mandrill.CWRU.Edu (ananth srinivasan) writes: >Does anyone know if there is a version of POSTGRES that is >available and can be purchased? What hardware environments >does it run on? Details would be appreciated. Anyone from >RTI out there?? Please e-mail your replies. Postgres is a reseach prototype system being developed at the University of California at Berkeley by Mike Stonebraker and I. We have not distributed it to anyone outside of our research groups yet. We hope to distribute version 1.0 (a limited function, slow, and probably buggy system) to a small group of alpha test sites (approx. 15) sometime this summer. As we complete more of the system and it becomes more stable we plan to distribute it more widely. I want to emphasize that this is a research prototype developed at U.C. Berkeley. It will be a public domain system that we distribute (source included) to anyone who wants it. RTI and other database vendors are free to pick the code up and do with it what they want. but, please don't expect much any time soon. Postgres is currently in about the same state University Ingres was in late 1975. It took 3 years to finally round out that system. larry rowe
fyl@ssc.UUCP (Phil Hughes) (12/21/89)
I hate to seem uninformed but what is POSTGRES?
--
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX
uunet!pilchuck!ssc!fyl or attmail!ssc!fyl (206)527-3385steve@violet.berkeley.edu (Steve Goldfield) (12/22/89)
In article <331@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes:
#>I hate to seem uninformed but what is POSTGRES?
#>--
#>Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX
I don't work on POSTGRES and hopefully someone who does will
respond to these questions, but until then, I'll post a bit of
the way they describe it in the research summary published by
the EECS department here at Berkeley. PLEASE DON'T SEND ME
EMAIL ASKING ME QUESTIONS ABOUT POSTGRES. I post this information
to give you some idea of what POSTGRES is about; you'll have to
get further details from those who designed and built it.
"In 1985, the INGRES
project embarked on the design and implementation of a new
database management system called POSTGRES (for "after INGRES")
and a new application development environment called PICASSO to
provide support for these applications." The principal objectives
of POSTGRES (the PI is Prof. M. R. Stonebraker), which is
described as a "next-generation database management system," are:
"(1) Simplify crash recovery code and provide access to
out-of-date data by keeping old data in the database rather than
in a separate long-term audit trail;
(2) Construct an implementation for the multiple, closely coupled
processors that will be prevalent on next-generation
workstations;
(3) Provide efficient support for versions;
(4) Provide support for extensible data types and extendable
indices;
(5) Support procedures as 'first-class' objects;
(6) Support triggers and inference."
More detailed project descriptions discuss a query optimizer,
which takes advantage of rapid increases in available main memory
and of parallel, shared-memory, multiprocessor computers; rule
management
Steve Goldfield
Industrial Liaison Program
College of Engineering, UC Berkeleysamuels@community-chest.uucp (Michael Samuels) (02/16/90)
Does anyone have any references and/or information on extended relational DBMSs, such as POSTGRES. I'm interested in the advantages/disadvantages of this approach to DB mgmt. vs. object-oriented DBMSs. Thanks. Michael Samuels The MITRE Corporation samuels@community-chest.mitre.org Mailstop Z676 (703) 883-7828 7525 Colshire Drive FAX: (703) 883-5519 McLean, VA 22102
kemnitz@postgres.uucp (Greg Kemnitz) (09/12/90)
What Is Postgres? In this brief discussion, I will try to clarify what Postgres is and what it is not. First, a quick summary: Postgres is a database research project under Prof. Michael Stonebraker at U. C. Berkeley. To facilitate research efforts, a software test-bed was created which is the "Postgres" software. The major purpose of this software is to provide a platform and a basis for the testing of implementations of new ideas in database research. Several graduate students, as well as undergraduate programmers and staff, have been working on the implementation of the Postgres software. After this paragraph, all references to "Postgres" refer to the software itself. What Postgres Is: o It is relational. One of the major goals of Postgres is to show that an essentially relational DBMS can be extended to handle complex objects, rules, and be highly extensible. Postgres is both relational and is an OODB. o Postgres is highly extensible, allowing user-defined operators, user-defined types, and user-defined functions. o Numerous other features which are beyond the scope of this discussion. For more detailed info, have a look at the tech reports which are available via anonymous FTP (see below). What Postgres is Not: o It is not an extension of University Ingres. No effort has been made to be compatible with University Ingres, and very little code is common. Questions about University Ingres should be posted to comp.databases. o It is not an attempt to create an industrial-strength public domain competitor to commercial DBMS offerings. We are not GNU. The Postgres group will support users as time permits, but user support is a secondary goal. o It is not a distributed database and there is no plan by our group at this time to make it distributed. o It does not use SQL. Getting Postgres: Postgres 2.0 (the current release) runs on SunOS 4.0.3 on Sparcstations (NOT SunOS 4.1), all SunOS on Sun 3's, on DECstation 3100's, and on Sequent Symmetry machines. It is available for anonymous FTP from postgres.berkeley.edu in the file pub/postgres-v2r0.tar.Z The installation instructions are in the file pub/postgres-setup.me Tech reports (which are also included in the tar file) are in the file pub/postgres-papers.tar.Z ----------------------------------------------------------------------- Greg Kemnitz | "I ran out of the room - I Postgres Chief Programmer | didn't want to be killed by a pile kemnitz@postgres.berkeley.edu | of ULTRIX manuals" :-) | | --A friend at DEC Palo Alto in the Quake
sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/14/90)
In article <27728@pasteur.Berkeley.EDU> kemnitz@postgres.berkeley.edu (Greg Kemnitz) writes: > ... >What Postgres Is: > >o It is relational. One of the major goals of Postgres is to show that > an essentially relational DBMS can be extended to handle complex objects, > rules, and be highly extensible. Postgres is both relational and is an > OODB. One could say that Postgres is _almost_ relational and _almost_ an OODB, but not fully either. Why not really relational: In a relational database, tuples must be accessible _only_ on the basis of their attribute values. Postgres adds immutable tuple identifiers that are visible to the user. Why not really object-oriented: One of the most important requirements of OO systems in general and OODB's in particular is strong object identity. The tuple identifiers of Postgres fall short because they are unique only within a relation (perhaps they can also be reused?). This is not to deny that Postgres is a highly interesting system. I have just suggested to a student to do her Master's thesis on it. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
mao@eden (Mike Olson) (09/14/90)
In <1990Sep14.065746.5711@tukki.jyu.fi>, sakkinen@jytko.jyu.fi (Markku Sakkinen) writes > One could say that Postgres is _almost_ relational and _almost_ an OODB, > but not fully either. > > ... > > Why not really object-oriented: One of the most important requirements > of OO systems in general and OODB's in particular is strong object > identity. The tuple identifiers of Postgres fall short because they > are unique only within a relation (perhaps they can also be reused?). if you have observed this behavior in the system, you have observed a bug. the intent of oid's (the name we use for tuple identifiers) is that they be unique within a database, not just a relation. we are aware that v2.0 (the most-recently released version of the system) can exhibit the behavior you've described not just across relations, but also within relations. the problem was that oid's were a function of time, rather than some something deterministic. the problems with this approach are too gory to go into. in any case, the oid allocation code now manages oids in the same way that transaction ids are allocated. we have a distinguished system relation subject to locking and access controls so that uniqueness is guaranteed. a side effect of this design is that no oid is ever reused within a database. i don't know when this code will be going out; send me email if you're interested, or contact the postgres@postgres mailing list. > This is not to deny that Postgres is a highly interesting system. > I have just suggested to a student to do her Master's thesis on it. great! we have a few of those here, as you might imagine. we are interested in any research results she might get from the system. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
davidm@uunet.UU.NET (David S. Masterson) (09/17/90)
In article <1990Sep14.065746.5711@tukki.jyu.fi> sakkinen@tukki.jyu.fi (Markku Sakkinen) writes: One could say that Postgres is _almost_ relational and _almost_ an OODB, but not fully either. Why not really relational: In a relational database, tuples must be accessible _only_ on the basis of their attribute values. Postgres adds immutable tuple identifiers that are visible to the user. Hmmm, doesn't the immutable tuple identifier agree with Codd/Date's RM/T database model with system generated primary keys? Might not an tupleID be considered just another attribute value? Why not really object-oriented: One of the most important requirements of OO systems in general and OODB's in particular is strong object identity. The tuple identifiers of Postgres fall short because they are unique only within a relation (perhaps they can also be reused?). What is Postgres' definition of an object instance? Does it correspond to a tuple? (I haven't seen Postgres, yet). -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
davidm@uunet.UU.NET (David S. Masterson) (09/17/90)
In article <27803@pasteur.Berkeley.EDU> mao@eden (Mike Olson) writes:
in any case, the oid allocation code now manages oids in the same way
that transaction ids are allocated. we have a distinguished system
relation subject to locking and access controls so that uniqueness is
guaranteed. a side effect of this design is that no oid is ever reused
within a database.
In that case, how many OIDs (and, I guess, transaction IDs) will be available
to a new database?
--
====================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"mao@eden (Mike Olson) (09/18/90)
in <CIMSHOP!DAVIDM.90Sep16215617@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes (re: postgres' use of persistent oids): > Hmmm, doesn't the immutable tuple identifier agree with Codd/Date's RM/T > database model with system generated primary keys? Might not an tupleID be > considered just another attribute value? we just consider it another attribute value, and it can be treated as such in user queries. the only problem in guaranteeing uniqueness is if you copy data out of one db and into another. in that case, you have to map the old oids somehow, to avoid collisions in the new db. any dependencies on oids as external keys in the user's schema is likely to break in this case. we ignore this problem for the time being, but if anyone has any really great ideas, we'd be happy to listen to them. > What is Postgres' definition of an object instance? Does it correspond to a > tuple? (I haven't seen Postgres, yet). postgres is able to treat tuples as objects, and in fact implements inheritance on relations, so tuples are the natural candidate for objects in any user schema. however, since we support user-defined data types as attributes in a relation, the user is free to create arbitrarily complex object implementations. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
mao@eden (Mike Olson) (09/18/90)
In <CIMSHOP!DAVIDM.90Sep16220527@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes (re: postgres object identifiers) > how many OIDs (and, I guess, transaction IDs) will be available > to a new database? object id's are longs -- you get 2^32 - 1 of them on all architectures on which postgres currently runs. 32767 of these are reserved for sytem use. transaction id's are 5-byte quantities, so you get 2^40 - 1 of them. note, however, that these are implementation details, and can be changed without breaking any other part of the system. a commercial implementation would probably choose to increase the number of available object identifiers. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
davidm@uunet.UU.NET (David S. Masterson) (09/19/90)
In article <27910@pasteur.Berkeley.EDU> mao@eden (Mike Olson) writes: In <CIMSHOP!DAVIDM.90Sep16215617@uunet.UU.NET>, [I] write: > Hmmm, doesn't the immutable tuple identifier agree with Codd/Date's RM/T > database model with system generated primary keys? Might not an tupleID > be considered just another attribute value? we just consider it another attribute value, and it can be treated as such in user queries. the only problem in guaranteeing uniqueness is if you copy data out of one db and into another. in that case, you have to map the old oids somehow, to avoid collisions in the new db. any dependencies on oids as external keys in the user's schema is likely to break in this case. we ignore this problem for the time being, but if anyone has any really great ideas, we'd be happy to listen to them. Would key constraints (either in the old database or the new database) provide the information you're looking for on avoiding key collision? Does Postgres implement constraints? What I mean is that if an attribute has a primary key constraint, then it is a candidate for a new set of OIDs on read-in. Also, if an attribute has a foreign key constraint, then it should map to the new values on the referred-to key. > What is Postgres' definition of an object instance? Does it correspond > to a tuple? (I haven't seen Postgres, yet). postgres is able to treat tuples as objects, and in fact implements inheritance on relations, so tuples are the natural candidate for objects in any user schema. however, since we support user-defined data types as attributes in a relation, the user is free to create arbitrarily complex object implementations. Is a user-defined data type considered an object? If so, does it have to map to a relation? If not, is there a formal mapping between what an object is and what a tuple is? between an object and an attribute? -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
sd9500@swpyr2.sbc.com (Steven K. Dieringer) (05/13/91)
Has anyone ported Postgres to the NeXT yet? Thanks in advance. Steve
rodney@tyrell.stgt.sub.org (Rodney Volz) (05/19/91)
In article <79@swpyr2.sbc.com> sd9500@swpyr2.sbc.com (Steven K. Dieringer) writes: > > Has anyone ported Postgres to the NeXT yet? > > Thanks in advance. > > Steve Has anyone managed to compile it under 386ix? Pls. send me mail. -Rodney -- Rodney Volz - 7000 Stuttgart 1 - FRG ============> ...uunet!mcsun!unido!gtc!aragon!tyrell!rodney <============= rodney@tyrell.gtc.de * rodney@delos.stgt.sub.org * rodney@mcshh.hanse.de \_____________ May your children and mine live in peace. ______________/