Gregory Stark <[EMAIL PROTECTED]> 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 6.7.2.2 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
