>> Uh, what did your CREATE TYPE command look like, exactly? This sounds
>> like you specified a default value for the datatype.
> [ no, he didn't ]
Now that I look at it, CREATE TYPE is totally whacked out about default
values for user-defined datatypes. The reason the system-defined types
all behave properly is that they are defined (in pg_type.h) with NULL
entries in the typdefault field of pg_type. But CREATE TYPE doesn't
fill in a NULL when it sees you haven't specified a default! Look at
TypeCreate in pg_type.c:
/* * initialize the default value for this type. */ values[i] = DirectFunctionCall1(textin, /* 17 */
CStringGetDatum(defaultTypeValue ? defaultTypeValue : "-"));
Yech, where'd that come from?
It turns out this doesn't hurt fixed-length types unless their length is
1, because there is a test in get_typdefault to verify that the stored
value is the expected length. But for var-length types the "-" comes
through.
A short-term workaround for Dave is to explicitly set pg_type.typdefault
to NULL after creating his type, but clearly we gotta clean this up.
ISTM that TypeCreate should set typdefault to NULL if it's passed a null
default-value item.
Another problem here is that there's no mechanism that causes the value
stored in typdefault to be correctly converted to the destination type.
DefineType and TypeCreate act as though the value is just a text string,
but then get_typdefault seems to think that it should find a text object
containing the *internal* representation of the desired value. Yech.
For example, to make an integer type with a default of 42, I'd have to
writedefault = '\0\0\0\52'
(which might or might not even work because of the nulls, and certainly
would not do what I wanted on a machine of the other endianness).
I propose that we define typdefault as containing the *external*
representation of the desired value, and have get_typdefault apply the
type's input conversion function to produce a Datum. Any objections?
regards, tom lane
