Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wO1s4-001GF3-36 for pgsql-general@arkaria.postgresql.org; Fri, 15 May 2026 23:23:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wO1s3-001xSF-2E for pgsql-general@arkaria.postgresql.org; Fri, 15 May 2026 23:23:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wO1s3-001xS7-1A for pgsql-general@lists.postgresql.org; Fri, 15 May 2026 23:23:07 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wO1s1-00000000pV4-0aMu for pgsql-general@postgresql.org; Fri, 15 May 2026 23:23:07 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 64FNMwec1439463; Fri, 15 May 2026 19:22:58 -0400 From: Tom Lane To: Ron Johnson cc: "pgsql-general@postgresql.org" Subject: Re: Suggestion for Easier Cross-Database Query Handling in PostgreSQL In-reply-to: References: Comments: In-reply-to Ron Johnson message dated "Fri, 15 May 2026 18:56:46 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1439461.1778887378.1@sss.pgh.pa.us> Date: Fri, 15 May 2026 19:22:58 -0400 Message-ID: <1439462.1778887378@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ron Johnson writes: > Why doesn't the shared OID space make cross-database queries possible? OIDs are not guaranteed unique across databases. To make this work transparently, we'd have to change all internal APIs to use database OID + object OID, not just object OID, as object identifiers. That would be horrendously invasive, not to mention probably costly in performance (by doubling the width of cache keys, for instance). But totally independently of implementation considerations, it's not apparent to me that this would be a good idea. As Frank mentioned, Postgres has always treated databases as isolation boundaries. Changing that would probably break a lot of peoples' installation designs. regards, tom lane