Re: [HACKERS] LZTEXT for rule plan stings
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] LZTEXT for rule plan stings |
Дата | |
Msg-id | 38B7C9F9.1E76D949@tm.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] LZTEXT for rule plan stings (Don Baccus <dhogaza@pacifier.com>) |
Ответы |
Re: [HACKERS] LZTEXT for rule plan stings
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: