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: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Bruce Momjian" <bruce(at)momjian(dot)us>, "David Fetter" <david(at)fetter(dot)org>
Subject: Re: Macros for typtype (was Re: Arrays of Complex Types)
Date: 2007-04-01 18:31:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> We could use enum {} to define the labels and then make a rule that
> all actual variables should be declared using "char" rather than
> declaring them as "enum typtype". But I fear somebody would get that
> wrong some day.

Yeah, that seems to me to be just asking for trouble.

> On the other hand it I don't really think it would cause any problems
> if people stored their typtypes in integers. Except for the actual
> FormData_pg_* structures the precise alignment doesn't actually matter
> for anything does it?

The layout of the FormData struct is exactly the sticking point.  If the
compiler makes the size or alignment of a struct field different from
what the tuple packing/unpacking code does for the corresponding column
type, we've got big trouble.

As for Peter's claim that the storage of an enum field is always int,
I think the C spec says otherwise.  In of C99 I see

    [#4] Each enumerated type shall be compatible with an
    integer type. The choice of type is
    implementation-defined, 97) but shall be capable of
    representing the values of all the members of the
    enumeration. The enumerated type is incomplete until after
    the } that terminates the list of enumerator declarations.

    97) An implementation may delay the choice of which integer
    type until all enumeration constants have been seen.

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.  So if we tried to
do this, we'd have the problem of needing compiler-specific data
type information entered in pg_type.

Perhaps all C compilers do this alike, but how would we know?
Anyway the possible gain seems not worth the risk to me.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-01 19:08:28
Subject: Re: Last minute mini-proposal (I know, Iknow)forPQexecf()
Previous:From: Andrew - SupernewsDate: 2007-04-01 15:44:17
Subject: Re: Bug in UTF8-Validation Code?

pgsql-patches by date

Next:From: Tom LaneDate: 2007-04-01 18:42:52
Subject: Re: Current enums patch
Previous:From: Magnus HaganderDate: 2007-04-01 17:40:55
Subject: Re: Blocked post

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