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

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 (view raw or flat)
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

pgsql-hackers by date

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

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