>> I thought about the huge size variable text type a little
>> more. And I think I could get the following implementation
>> to work reliable for our upcoming release.
>>
>> For any relation, having one or more LONG data type
>> attributes, another relation (named pg_<something>) is
>> created, accessible only to superusers (and internal access
>> routines). All LONG data items are stored as a reference
>> into that relation, split up automatically so the chunks fit
>> into the installation specific tuple limit size. Items are
>> added/updated/removed totally transparent.
> Should we use large objects for this, and beef them up. Seems that
> would be a good way.
Yes, I think what Jan is describing *is* a large object, with the
slight change that he wants to put multiple objects into the same
behind-the-scenes relation. (That'd be a good change for regular
large objects as well ... it'd cut down the umpteen-thousand-files
problem.)
The two principal tricky areas would be (1) synchronization ---
having one hidden relation per primary relation might solve the
problems there, but I'm not sure about it; and (2) VACUUM.
But I don't really see why this would be either easier to do or
more reliable than storing multiple segments of a tuple in the
primary relation itself. And I don't much care for
institutionalizing a hack like a special "LONG" datatype.
regards, tom lane