From 79729c0e5efab44c764a69ceaa9d52ecd6be1ce5 Mon Sep 17 00:00:00 2001 From: Bryan Henderson Date: Mon, 9 Dec 1996 01:23:51 +0000 Subject: [PATCH] Add comments defining "typelem" column of pg_type. --- src/include/catalog/pg_type.h | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/src/include/catalog/pg_type.h b/src/include/catalog/pg_type.h index ac87e90aa3..47179b95c0 100644 --- a/src/include/catalog/pg_type.h +++ b/src/include/catalog/pg_type.h @@ -7,7 +7,7 @@ * * Copyright (c) 1994, Regents of the University of California * - * $Id: pg_type.h,v 1.4 1996/11/13 20:51:06 scrappy Exp $ + * $Id: pg_type.h,v 1.5 1996/12/09 01:23:51 bryanh Exp $ * * NOTES * the genbki.sh script reads this file and generates .bki @@ -43,17 +43,17 @@ CATALOG(pg_type) BOOTSTRAP { int2 typlen; /* typlen is the number of bytes we use to represent a value of this type, e.g. 4 for an int4. But for a variable length - attribute, typlen is -1. + type, typlen is -1. */ int2 typprtlen; bool typbyval; /* typbyval determines whether internal Postgres routines pass a value of this type by value or by reference. Postgres uses a 4 byte - area for passing class data, so if the value is not 1, 2, + area for passing a field value info, so if the value is not 1, 2, or 4 bytes long, Postgres does not have the option of passing by value and ignores typbyval. - (I don't understand why this attribute exists. The above description + (I don't understand why this column exists. The above description may be an oversimplification. Also, there appear to be bugs in which Postgres doesn't ignore typbyval when it should, but I'm afraid to change them until I see proof of damage. -BRYANH 96.08). @@ -63,6 +63,10 @@ CATALOG(pg_type) BOOTSTRAP { char typdelim; Oid typrelid; Oid typelem; + /* typelem is NULL if this is not an array type. If this is an array + type, typelem is the OID of the type of the elements of the array + (it identifies another row in Table pg_type). + */ regproc typinput; regproc typoutput; regproc typreceive; @@ -71,7 +75,7 @@ CATALOG(pg_type) BOOTSTRAP { /* typalign is the alignment required when storing a value of this type. It applies to storage on disk as well as most representations of the value inside Postgres. When multiple values are stored - consecutively, such as in the representation of a complete tuple + consecutively, such as in the representation of a complete row on disk, padding is inserted before a datum of this type so that it begins on the specified boundary. The alignment reference is the beginning of the first datum in the sequence. @@ -88,7 +92,7 @@ CATALOG(pg_type) BOOTSTRAP { } TypeTupleFormData; /* ---------------- - * Form_pg_type corresponds to a pointer to a tuple with + * Form_pg_type corresponds to a pointer to a row with * the format of pg_type relation. * ---------------- */ @@ -153,7 +157,7 @@ DATA(insert OID = 22 ( int28 PGUID 16 50 f b t \054 0 21 int28in int28ou * go away someday. until that happens, there is a case (in the * catalog cache management code) where we need to step gingerly * over piles of int28's on the sidewalk. in order to do so, we - * need the OID of the int28 tuple from pg_type. + * need the OID of the int28 row from pg_type. */ #define INT28OID 22 -- 2.40.0