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