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: 17 Sep 90 05:05:27 GMT References: <556@mcspdx.pdx.csd.mot.com> <27728@pasteur.Berkeley.EDU> <1990Sep14.065746.5711@tukki.jyu.fi> <27803@pasteur.Berkeley.EDU> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 17 In-reply-to: mao@eden's message of 14 Sep 90 14:14:10 GMT 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!"