Re: [HACKERS] text should be a blob field - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] text should be a blob field
Date
Msg-id 199803031435.JAA29190@candle.pha.pa.us
Whole thread Raw
In response to text should be a blob field  (Zeugswetter Andreas SARZ <Andreas.Zeugswetter@telecom.at>)
Responses Re: [HACKERS] text should be a blob field  (Peter T Mount <psqlhack@maidast.demon.co.uk>)
List 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 by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Lost a function overloading capability in v6.3
Next
From: t-ishii@sra.co.jp
Date:
Subject: Re: [HACKERS] Current 6.3 issues