Tom Lane wrote:
> Bernd Helmle <mailings@oopsware.de> writes:
>> It might be interesting to dig into your proposal deeper in conjunction
>> with TOAST (you've already mentioned this TODO). Having serial access with
>> a nice interface into TOAST would be eliminating the need for
>> pg_largeobject completely (i'm not a big fan of this one-big-system-table
>> approach the old LO interface currently is).
>
> Yeah, it would be more useful probably to fix that than to add
> decoration to the LO facility. Making LO more usable is just going to
> encourage people to bump into its other limitations (32-bit OIDs,
> 32-bit object size, finite maximum size of pg_largeobject, lack of
> dead-object cleanup, etc etc).
The reason why I tried to mention the named largeobject feature is
that dac security checks on largeobject require them to belong to
a certain schema, so I thought it is quite natural to have a string
name. However, obviously, it is not a significant theme for me.
I can also agree your opinion that largeobject interfaces should be
redefined to access partial stuff of TOAST'ed verlena data structure,
not only pg_largeobject.
In this case, we will need a new pg_type.typstorage option which
force to put the given verlena data on external relation without
compression, because we cannot estimate the data offset in inlined
or compressed external verlena data.
I'll try to submit a design within a few days.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
