Re: pg_class catalog question...

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Thomas Hallgren <thomas(at)tada(dot)se>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_class catalog question...
Date: 2006-04-02 18:50:38
Message-ID: 20060402185038.GK49405@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 01, 2006 at 05:42:34PM +0200, Thomas Hallgren wrote:
> Jim C. Nasby wrote:
> >On Fri, Mar 31, 2006 at 11:29:15AM -0500, Tom Lane wrote:
> >>This argument falls flat when you consider that the width of a CHAR
> >>entry is measured in characters, not bytes, and therefore its physical
> >>size is not fixed even if its logical width is.
> >
> >True, but in every case I've used char it was to store something that
> >would never be multi-byte, like a GUID, or a SHA1. Though I guess in
> >retrospect, what would really be handy is 'hex' datatype, that stores a
> >hex string (possibly with a custom format, such as a GUID) in it's
> >native binary format.
>
> Why not simply a fixed number of bytes, i.e. byte(16) or octet(16)?
> Hexadecimal is just a convenient human-readable representation.

Well, hex is much easier to deal with in many regards than raw bytes,
though. But yes, the idea is that you'd just store raw bytes on disk.
byte or octet would work fine if they existed.
--
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 Thomas Hallgren 2006-04-02 18:53:46 Re: pg_class catalog question...
Previous Message Tom Lane 2006-04-02 16:40:30 uh-oh, buildfarm all red