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

Re: Macros for typtype (was Re: Arrays of Complex Types)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Macros for typtype (was Re: Arrays of Complex Types)
Date: 2007-04-02 04:11:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> It seems clear to me that this authorizes, but *does not require*,
>> the compiler to store an enum field in a byte or short instead of
>> an int when all the declared values will fit.

> FWIW, I never meant to suggest using enums tuple structures.  I did, 
> however, stumble over a case that appears to be handled similar to what 
> I had in mind: see enum CoercionCodes in primnodes.h.  Again, it's not 
> really important, but it's interesting to see that there is precedent.

AFAIK, we don't store CoercionCodes in any system catalog columns.
But now that you mention it there is at least one place where we do
it like that: pg_depend.deptype is a "char" but its values are defined
by enum DependencyType.  I have some recollection of doing it that way
because I was concerned that most places that cared about dependency
types should be switch statements that covered all the possible values
(which is pretty much the only benefit you get from doing it that way).
Having just gone over the typtype uses, there are only a couple of
places where we'd win from having that sort of compile-time check for

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-02 04:32:52
Subject: Re: Bug in UTF8-Validation Code?
Previous:From: Andrew DunstanDate: 2007-04-02 01:47:06
Subject: Re: Column storage positions

pgsql-patches by date

Next:From: ITAGAKI TakahiroDate: 2007-04-02 04:56:04
Subject: UTF8MatchText
Previous:From: Tom LaneDate: 2007-04-02 03:57:48
Subject: Re: Current enums patch

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