Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1poRYx-0004jx-B3 for pgsql-bugs@arkaria.postgresql.org; Mon, 17 Apr 2023 16:18:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1poRYw-0004Dr-8P for pgsql-bugs@arkaria.postgresql.org; Mon, 17 Apr 2023 16:18:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1poRYw-0004Di-0E for pgsql-bugs@lists.postgresql.org; Mon, 17 Apr 2023 16:18:42 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1poRYt-000LUb-Nr for pgsql-bugs@lists.postgresql.org; Mon, 17 Apr 2023 16:18:40 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 33HGIbTX2444932; Mon, 17 Apr 2023 12:18:38 -0400 From: Tom Lane To: Greg Stark cc: "David G. Johnston" , "thierrym@gmail.com" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields. In-reply-to: References: <17902-e75daa72de96a626@postgresql.org> Comments: In-reply-to Greg Stark message dated "Mon, 17 Apr 2023 11:51:49 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2444930.1681748317.1@sss.pgh.pa.us> Date: Mon, 17 Apr 2023 12:18:37 -0400 Message-ID: <2444931.1681748317@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Greg Stark writes: > But large objects are kind of a leaky abstraction in that the internal > ID becomes a user-visible identifier that is the only way users have > of referencing these objects. > I could see it being pretty useful to have an user-controlled > identifier instead of forcing users to use OIDs. You already can create LOBs with any identifier you want, as long as it's an int4. The OP seems to think he can mix manual allocation with automatic allocation of those IDs and it should just work. > But the bad news is that I don't think anyone's really excited about > working on the LOB facility. Yeah. There's been some discussion of widening the identifiers to int8, but I can't see going further than that. UUIDs would be a disaster for a number of reasons, both performance and compatibility related. regards, tom lane