Re: [HACKERS] Priorities for 6.6

Don Baccus wrote:
>
> At 05:39 PM 6/3/99 -0400, Tom Lane wrote:
>
> > * Allow large text type to use large objects(Peter)
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > I like it very much, though I don't like that LO are stored
> > in separate files. This is known as "multi-representation" feature
> > in Illustra.
> >
> >But, but ... if we fixed the tuple-size problem then people could stop
> >using large objects at all, and instead just put their data into tuples.
> >I hate to see work going into improving LO support when we really ought
> >to be phasing out the whole feature --- it's got *so* many conceptual
> >and practical problems ...
>
> Making them go away would be a real blessing. Oracle folk
> bitch about CLOBS and BLOBS and the like, too. They're a
> pain.

Note: I told about "multi-representation" feature, not just about
LO/CLOBS/BLOBS support. "Multi-representation" means that server
stores tuple fields sometime inside the main relation file,
sometime outside of it, but this is hidden from user and so
people "just put their data into tuples". I think that putting
big fields outside of main relation file is very good thing.
BTW, this approach also allows what you are proposing - why not
put not too big field (~ 8K or so) to another block of main file?
BTW, I don't like using LOs as external storage.

Implementation seems easy:

struct varlena
{
int32 vl_len;
char vl_dat[1];
};

1. make vl_len uint32;
2. use vl_len & 0x80000000 as flag that underlying data is
in another place;
3. put oid of external "relation" (where data is stored),
blocknumber and item position (something else?) to vl_dat.
...
...
...

Vadim