Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

> make text a blob datatype (maybe storing <= 8k row with tuple, >=8k in blob
> tablespace)


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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group