Re: [HACKERS] text should be a blob field

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Andreas(dot)Zeugswetter(at)telecom(dot)at (Zeugswetter Andreas SARZ)
Cc: pgsql-hackers(at)hub(dot)org, questions(at)postgreSQL(dot)org (PostgreSQL-questions)
Subject: Re: [HACKERS] text should be a blob field
Date: 1998-03-03 14:35:09
Message-ID: 199803031435.JAA29190@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message t-ishii 1998-03-03 14:41:56 Re: [HACKERS] Current 6.3 issues
Previous Message Thomas G. Lockhart 1998-03-03 14:33:47 Re: [HACKERS] Lost a function overloading capability in v6.3