Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields.
От | Greg Stark |
---|---|
Тема | Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields. |
Дата | |
Msg-id | CAM-w4HPP8Ki33mqkv10aYuMZMJwMuX4xyZ1_6r9yqg+iGLFFgQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields. ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields.
|
Список | pgsql-bugs |
On Mon, 17 Apr 2023 at 10:49, David G. Johnston <david.g.johnston@gmail.com> wrote: > > This isn’t a bug and changing OIDs from integers to UUIDs isn’t going to happen. Hm. Changing OIDs to UUIDs on catalog tables isn't going to happen. 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. Like, the only good solution for this case that I see is to have a mapping table so they would load the new LOBs and get new OIDs and then run a program to pick up the UUIDs from within the JSON and store new mappings. That's a pain and I don't see any reason for that mapping to be in a separate table instead of in the LOB table itself. But the bad news is that I don't think anyone's really excited about working on the LOB facility. It's more than a decade old and I don't think there's been any new features or optimization work done on it in at least that long. I think most users who would drive any new work on it end up deciding to use some external-to-the-database object store and store references in the database. (which has issues with backups and failovers getting out of sync but on the flip side makes backups and replication way easier to manage resources for) -- greg
В списке pgsql-bugs по дате отправления: