Path: utzoo!attcan!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: Postgres (was Re: Public Domain Databases) Message-ID: Date: 18 Sep 90 17:34:34 GMT References: <556@mcspdx.pdx.csd.mot.com> <27728@pasteur.Berkeley.EDU> <1990Sep14.065746.5711@tukki.jyu.fi> <27910@pasteur.Berkeley.EDU> Sender: davidm@cimshop.UUCP Followup-To: comp.databases Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 42 In-reply-to: mao@eden's message of 17 Sep 90 18:20:59 GMT In article <27910@pasteur.Berkeley.EDU> mao@eden (Mike Olson) writes: In , [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!"