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.
regards, tom lane