Avin Kavish <avinkavish@xxxxxxxxx> writes: > On Sun, Jul 21, 2019 at 10:24 AM jmz <mxav1111@xxxxxxxxx> 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. regards, tom lane
