Re: [HACKERS] text should be a blob field
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] text should be a blob field |
Дата | |
Msg-id | 199803031435.JAA29190@candle.pha.pa.us обсуждение исходный текст |
Ответ на | text should be a blob field (Zeugswetter Andreas SARZ <Andreas.Zeugswetter@telecom.at>) |
Ответы |
Re: [HACKERS] text should be a blob field
|
Список | pgsql-hackers |
> > Of course a first mail after a release must have the earned praise: > Very nicely done, I like it all ;-) > > Reading the TODO, I see 'Allow text, char(), and varchar() overhead to be > only 2 bytes, not 4 bytes' > While this is very good for char and varchar, text is not a candidate > since it is usually a blob datatype, without a length restriction (or a 2Gig > limit). It was an idea. I think I will remove it from the TODO list. I had considered it so I could save the defined length(atttypmod now) in there, but now that we have atttypmod, we don't need it. It will stay at 4 bytes. > > I think it should alternately read: > Allow varchar() overhead to be only 2 bytes > remove char() 4 byte overhead, use atttypmod instead Ooh, this is interesting. Yea, I guess we really don't need that for char() anymore. The only problem is that we would have to do some fancy stuff to track char() separately in the backend, and I am sure atttypmod is not available in all the places we need it. Don't think it is worth it. > make text a blob datatype (maybe storing <= 8k row with tuple, >=8k in blob > tablespace) Hmmm. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: