| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "thierrym(at)gmail(dot)com" <thierrym(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields. |
| Date: | 2023-04-17 16:18:37 |
| Message-ID: | 2444931.1681748317@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Greg Stark <stark(at)mit(dot)edu> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2023-04-18 10:16:00 | Re: BUG #17847: Unaligned memory access in ltree_gist |
| Previous Message | Greg Stark | 2023-04-17 15:51:49 | Re: BUG #17902: export/import tenant not possible due to PG internal id on jsonB fields. |