Re: pg_class catalog question...

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_class catalog question...
Date: 2006-03-31 16:07:04
Message-ID: 20060331160703.GQ49405@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 31, 2006 at 10:45:15AM -0500, Jonah H. Harris wrote:
> On 3/31/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> > What are you using a char[64] for anyway? You should probably consider
> > using NameData, if you want to store an identifier.
>
> It's just a fixed length string that will never change in size and as
> such, I'd like not to add the overhead of any variable-length
> handling.

What about creating a fixed-size general purpose type?

About the only reason I use CHAR in other databases systems is when I
know that the field will always contain the same amount of data, ie:
storing a SHA1. In these cases it's silly to have a 4 byte overhead to
store length. I really wish CHAR in PostgreSQL worked this way, so it
would be a welcome addition to have a type that did work this way. In
fact, I'd argue that CHAR should be made to work that way, and what's
currently called CHAR should be renamed for those who wish to use it.
I've yet to run across a use for CHAR where you might actually have a
variable amount of data stored and just want to enforce a certain number
of space padding.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 2006-03-31 16:18:27 Re: Slony-I for circular replication
Previous Message Jonah H. Harris 2006-03-31 15:45:15 Re: pg_class catalog question...