Cursory reference to OID info explains that it is 4 byte unsigned integer. Not sure if size can be increased or else
Can we change OID creation routine to take hostname-(cloud/domain) into consideration? Yes only newly created database can take full advantage of this change but it is reasonable limitation if it is not too much of a dev challenge.
Avin Kavish <avinkavish@gmail.com> writes: > On Sun, Jul 21, 2019 at 10:24 AM jmz <mxav1111@gmail.com> wrote: >> Thank you for the clarification David. I really thought this would be >> easier to implement since rest of the architecture (within DB) doesn't need >> any (or little) change.
> If you are referring to cross database queries using that syntax wouldn't > that require reworking the transaction system to work across db's to > guarantee ACIDity?
The transaction system wouldn't particularly care, since XIDs are cluster-wide already. However, there is no provision at all for cross-database catalog access, and that's where the problems would start.
As an example, there is an assumption throughout the backend that table names can be resolved into OIDs at parse time and the OID is a sufficiently unique identifier from then on. But an OID is a lookup key for only one database's pg_class catalog. There's no guarantee that table OIDs are unique across databases, much less any efficient way to find the referent of an OID that perhaps points into some other database's pg_class.
Likewise for functions. Likewise for operators, and most other sorts of named entities. The only things for which OIDs are effectively cluster-wide are the object types tracked in shared catalogs (roles, tablespaces, databases).
You could imagine, perhaps, converting *all* the catalogs to be shared across databases, but that's not going to happen for a number of good reasons, such as performance, reliability, and security.
In short, the OP's notion that this would be a minor change is utterly uninformed. I'd put the odds that it ever happens at epsilon.