Path: utzoo!attcan!uunet!know!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!dog.ee.lbl.gov!pasteur!eden!mao From: mao@eden (Mike Olson) Newsgroups: comp.databases Subject: Re: Postgres (was Re: Public Domain Databases) Message-ID: <27910@pasteur.Berkeley.EDU> Date: 17 Sep 90 18:20:59 GMT References: <556@mcspdx.pdx.csd.mot.com> <27728@pasteur.Berkeley.EDU> <1990Sep14.065746.5711@tukki.jyu.fi> Sender: news@pasteur.Berkeley.EDU Reply-To: mao@postgres.Berkeley.EDU (Mike Olson) Followup-To: comp.databases Organization: University of California, Berkeley Lines: 27 in , 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