Don Baccus wrote:
>
> Boy, I'd sure find it desirable. There's nothing to stop people from
> using varchar(8000) or whatever if they want a predictable top limit.
> Text is not a standard type, and this wouldn't break standard semantics.
>
> lzText wasn't removed because folks thought it was useless, IIRC,
> it was removed because TOAST was an exciting and much more powerful
> approach and no one wanted to introduce a new type doomed to disappear
> after a single release cycle.
>
> With TOAST, from the user's point of view you'll still have an
> _undefined_ max tuple length - the max will just be really, really
> large. Sure, the tuples will actually be fixed but large varying
> types can be split off into a series of tuples in the TOASTer
> oven, so to speak. So I guess I have difficulty understanding
> your argument.
Acutually it was not undefined but variable that made me uncertain -
i.e. the fact that max size depends on the contents of string
> If text were implemented as lzText for a quick 7.1, which apparently
> was Jan's spin on the idea, then for 7.1 we'd say:
>
> "maximum number of characters you can store in a column of type
> text varies"
... varies from below 8K to ~100K depending on the redundancy of data"
> and after TOAST we'd say:
>
> "maximum number of characters you can store in a column of type
> text varies"
Rather "maximum number of characters you can store in a column of type text is limited by available memory and/or disk
space"
-----------------
Hannu