> text_enum: same problem as above, plus not acceptable to assume that it
> gets the right enum OID, plus very definitely not acceptable to assume
> that OID and typmod are the same size, plus I don't like the
> undocumented kluge in getBaseTypeAndTypmod that is pretending to supply
> the type OID for some small fraction of possible invocation cases.
>
> I think text_enum is probably toast.
This was the ugliest part of the patch, and I mentioned it explicitly in
the original submission because I was uncomfortable about it. The proper
solution seemed to be to have another allowed cast function signature
that would take the regtype rather than the typmod. That got just a
little beyond what I wanted to do in the patch, and ugly as the
getBaseTypeAndTypmod hack was, it seemed less intrusive.
Another way to skirt the issue was to simply set the typmod of enum
types to have their own OID, but a) I wasn't sure what other things the
system might be inferring from the presence of a typmod, and b) you just
stated that we can't assume that typmod is big enough to hold an OID anyway.
I'm less concerned about the generic return type in this case, since the
parser should know the return type when an explicit cast has been
called. <Goes to check> Hmm, ok, maybe not. Looks like it's using the
return type of the cast function and throwing away the explicit cast
information. That's not very nice, but can probably be fixed in the parser.
Thoughts?
Tom
