Re: Database.Schema.Table

Thanks Tom. Explanation is very insightful.
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.

Best,
Max

On Sun, Jul 21, 2019, 07:36 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Avin Kavish <avinkavish(at)gmail(dot)com> writes:
> > On Sun, Jul 21, 2019 at 10:24 AM jmz <mxav1111(at)gmail(dot)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
>