On 3 Sep 2003 at 10:27, Malcolm Warren wrote:
> To sum up: The Debian migration gzip file declares that oids are not
> guaranteed to be unique, issues dire warnings about using them as keys and
> worst of all states that they may be phased out in the future.
>
> The book states that they are unique, tells you how to use them, actually
> gives an example of using them as primary and foreign keys (which
> fortunately I decided was not very wise) and certainly doesn't say anything
> about phasing them out in the future.
Yes. It is correct. As of 7.3.x and onwards oids are optional at table creation
times. They default to be available for new objects but that is for backwards
compatibility I believe. In future, they would default to be not available for
a particular object(hopefully). Right now you need to explicitly specify no
oids while creating tables etc.
About oids not being unique, oids can assume 4 billion different values. If you
have more than those many rows in a table, oids will wrap around and will no
longer be unique in that object.
About oids being eliminated, I am sure it would happen some time in the future,
looking at the development on this issue. Core team could elaborate more on
this.
Correct me if I am wrong.
HTH
Bye
Shridhar
--
Nusbaum's Rule: The more pretentious the corporate name, the smaller the
organization. (For instance, the Murphy Center for the Codification of Human
and Organizational Law, contrasted to IBM, GM, and AT&T.)
